Re: [Interest] Qt 5.9 and OpenSSL 1.1?
On 9/17/19 5:00 AM, Thiago Macieira wrote: It's believed the Stuxnet attack against Iran's nuclear energy labs was started by dropping USB flash drives in the parking lot. While there are hacker groups who operate that way, I'm not buying the story. Mainly I don't buy it because the "security videos" or whatever they were called put out as part of the propaganda for the facility showed everyone wearing the white bunny suits. Getting a flash drive through the airgap inspection barrier would require someone to palm it rather skillfully (assuming those really are the one piece bunny suits without pockets.) https://www.wsj.com/video/opinion-iran-uranium-enrichment-is-a-step-towards-nuclear-weapons/9D7ACDE8-7AAA-4DA9-A8A2-E3C5177DCD7F.html A much more plausible story was put out by a retired U-2 pilot in "A Dangerous Element." https://www.barnesandnoble.com/w/a-dangerous-element-gregory-s-lamb/1117800520 It was an "activity tracker" watch. Been a while since I read the book, but I believe the story relied on bluetooth security (non-existent in early bluetooth products) ala "Person of Interest" phone cloning. https://en.wikipedia.org/wiki/Activity_tracker https://www.imdb.com/title/tt1839578/?ref_=nv_sr_1?ref_=nv_sr_1 The book is a good read and activity trackers fit the time frame too. The long sleeved bunny suit would have easily covered up a watch if security was even considering a watch a threat back then. The story, according to the book, about how it "got out" was that he kept the watch on all of the time even when using his home computer. I know Wikipedia is pushing the flash drive story but the story in that book is much more believable. Adding insult to injury is a medical device manufacturer I've dealt with has for _years_ had computers which not only shut down if a flash drive is plugged in, they will not reboot. You have to take them into security, undergo and interrogation and most likely be escorted from the property. The last time I talked with them I was told they wanted me to replace someone who had just discovered that particular mystery of life. That place makes infusion pumps for cancer patients. They don't refine radioactive material or do anything clandestine. They all looked like ordinary Dell laptops to me. Personally I just find it incredible that a facility engaged in enrichment would allow USB ports to be both exposed and unsecured. -- Roland Hughes, President Logikal Solutions (630)-205-1593 http://www.theminimumyouneedtoknow.com http://www.infiniteexposure.net http://www.johnsmith-book.com http://www.logikalblog.com http://www.interestingauthors.com/blog ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Expected event execution order in this multi-thread application
30.09.2019, 11:38, "Rainer Wiesenfarth" : > On Mon, Sep 30, 2019 at 9:26 AM Thiago Macieira > wrote: >> [...] Anyway, this is when you should use processEvents(): never. > > ...which would be a perfect reason to at least mark it as obsolete in Qt 6? I would strongly oppose such deprecation, as it would break a few places in QtWebKit where it's used to integrate non-Qt code with Qt event loop > > I strongly second Thiago's recommendation: processEvents() usually introduces > more problems than it solves. > > -- > Software Engineer | Trimble Imaging Division > Rotebühlstraße 81 | 70178 Stuttgart | Germany > Office +49 711 22881 0 | Fax +49 711 22881 11 > http://www.trimble.com/imaging/ | http://www.inpho.de/ > > Trimble Germany GmbH, Am Prime Parc 11, 65479 Raunheim > Eingetragen beim Amtsgericht Darmstadt unter HRB 83893, > Geschäftsführer: Dr. Frank Heimberg, Jürgen Kesper > , > > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest -- Regards, Konstantin ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Expected event execution order in this multi-thread application
On Monday, 30 September 2019 08:05:23 PDT Ola Røer Thorsen wrote:
> man. 30. sep. 2019 kl. 16:48 skrev Thiago Macieira <
>
> thiago.macie...@intel.com>:
> > It's just wrong to use it. Just like QThread::{,m,u}sleep. Don't use them.
>
> What's wrong with the sleep functions in particular? Are they worse than
> calling for example unistd.h's "usleep" or
> "std::this_thread::sleep_for(std::chrono::milliseconds(x));"?
The problem with the sleep functions is that they sleep for an amount of time
different than the actual amount of time that you needed to sleep for.
Note: *needed* to sleep for, not *coded* for. Pretty much any time span
different from 0 is wrong in at least one circumstance: either you're sleeping
too little, in which case you woke the system up early and are consuming CPU
time and battery, or you slept too much and you delayed processing some
incoming event.
Usually, it's both: you wake up early, consume battery, handle no events, then
go back to sleep. Then the event you needed to handle arrives while you're
still sleeping.
Don't sleep with a timeout. Sleep until *exactly* your event arrives, no
sooner and no later.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] Expected event execution order in this multi-thread application
On Monday, 30 September 2019 09:35:48 PDT Uwe Rathmann wrote: > On 9/30/19 4:43 PM, Thiago Macieira wrote: > > It's not advisable to use nested event loops. > > It is not the first time that you gave this warning, but something like > QDialog::exec is simply too handy for GUI development. Which is why we can't remove such functions. They're too handy. Even if they introduce hard to debug issues because events get handled out of order, states change from underneath signal emitters, etc. > And yes: issues like this one ( > https://bugreports.qt.io/browse/QTBUG-73432 ) belong to the category of > problems that should not exist. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Expected event execution order in this multi-thread application
On 9/30/19 4:43 PM, Thiago Macieira wrote: It's not advisable to use nested event loops. It is not the first time that you gave this warning, but something like QDialog::exec is simply too handy for GUI development. Of course there are known side effects, but IMHO it should be the job of a GUI framework to solve them as good as possible to make the life of the application programming easier. And yes: issues like this one ( https://bugreports.qt.io/browse/QTBUG-73432 ) belong to the category of problems that should not exist. Uwe ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Expected event execution order in this multi-thread application
On Mon, Sep 30, 2019 at 6:07 PM Ola Røer Thorsen wrote: > What's wrong with the sleep functions in particular? > They're uninterruptible. In 99.9(9)% of cases there's a better way to suspend a thread for some time than unconditionally putting it to sleep. > Are they worse than calling for example unistd.h's "usleep" or > "std::this_thread::sleep_for(std::chrono::milliseconds(x));"? > No. ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Expected event execution order in this multi-thread application
man. 30. sep. 2019 kl. 16:48 skrev Thiago Macieira <
thiago.macie...@intel.com>:
>
> It's just wrong to use it. Just like QThread::{,m,u}sleep. Don't use them.
>
>
What's wrong with the sleep functions in particular? Are they worse than
calling for example unistd.h's "usleep" or
"std::this_thread::sleep_for(std::chrono::milliseconds(x));"?
Cheers,
Ola
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] Expected event execution order in this multi-thread application
On Monday, 30 September 2019 01:34:25 PDT Rainer Wiesenfarth wrote:
> > [...] Anyway, this is when you should use processEvents(): never.
>
> ...which would be a perfect reason to at least mark it as obsolete in Qt 6?
It's not obsolete. It's not broken.
It's just wrong to use it. Just like QThread::{,m,u}sleep. Don't use them.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] Expected event execution order in this multi-thread application
On Monday, 30 September 2019 01:33:12 PDT Richard Weickelt wrote: > Because I attached a debugger and stopped T1 during > QCoreApplication::processEvents(). I can see E3 (the one that the thread is > currently processing) in postEventList at index 0 and E2 at index 1. That's > it. From there I see the following call chain > QEventDispatcherGlib::processEvents() followed by emit awake() because > canWait is false. I haven't traced it further. The signal emission doesn't > have any consequence in the event loop though. Can you check what happens when it calls into QCoreApplicationPrivate::sendPostedEvents()? That function should loop from data->postEventList.startOffset to data->postEventList.size() (size at the time you call into the function, so no new events wil be handed). Like you said, it should be handled on the first iteration after it's been queued. > > Anyway, this is when you should use processEvents(): never. > > It is a public API and it is not marked as deprecated. If the function does > not behave as documented, then either the documentation is wrong or the > implementation has a bug or I am using it the wrong way. I don't think the > latter is the case, but maybe I need a minimal test case to prove that. It's not broken, that's why it's not deprecated. But that doesn't mean it's a good API. It's not advisable to use nested event loops. processEvents() is just the worst kind of nested event loops. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Expected event execution order in this, multi-thread application
On 9/30/19 3:51 AM, Rainer Wiesenfarth wrote: ...which would be a perfect reason to at least mark it as obsolete in Qt 6? It cannot be obsoleted because there is too much bad code out there relying on it. Bad examples doing database I/O and serial I/O within the main event loop, etc. I strongly second Thiago's recommendation: processEvents() usually introduces more problems than it solves. -- Roland Hughes, President Logikal Solutions (630)-205-1593 http://www.theminimumyouneedtoknow.com http://www.infiniteexposure.net http://www.johnsmith-book.com http://www.logikalblog.com http://www.interestingauthors.com/blog ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Interest Digest, Vol 96, Issue 29
On 9/30/19 3:51 AM, interest-requ...@qt-project.org wrote: Anyway, DON'T use processEvents(). Redesign your code. It's unfortunately QScriptEngine which calls this method, triggered by a periodic timer. The application is Qbs and it is blackboxtest::concurrentExecution which triggers that behavior. It processes a long-running script that expects a file to appear in the file system produced by another thread. But for this to happen, the current execution thread needs to handle events. The testcase usually behaves as expected, but in rare cases it doesn't and that is what I am currently investigating.https://bugreports.qt.io/browse/QBS-1499 Before I suggest an action, I want to understand the error. If you are "waiting for a file to appear" you should probably look into https://doc.qt.io/qt-5/qfilesystemwatcher.html Sure, but I don't see a synchronization problem as long if QCoreApplication::processEvents() would do what the documentation says: executing pending events in the current thread. Am I misunderstanding something? If you are relying on processEvents() you have a synchronization problem. This application needs an architect. Anyway, this is when you should use processEvents(): never. It is a public API and it is not marked as deprecated. If the function does not behave as documented, then either the documentation is wrong or the implementation has a bug or I am using it the wrong way. I don't think the latter is the case, but maybe I need a minimal test case to prove that. -- Roland Hughes, President Logikal Solutions (630)-205-1593 http://www.theminimumyouneedtoknow.com http://www.infiniteexposure.net http://www.johnsmith-book.com http://www.logikalblog.com http://www.interestingauthors.com/blog ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] [SPAM] Multiple displays support on i.MX8 and EGLFS Inbox
Spam detection software, running on the system "mx.qt-project.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hi, I've asked in the forum about support for multiple displays when using i.MX8 and EGLFS, and they suggested to ask here: https://forum.qt.io/topic/106976/multiple-displays-support-on-i-mx8-and-eglfs [...] Content analysis details: (4.8 points, 4.6 required) pts rule name description -- -- 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4917] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (diego.ml[at]zoho.com) 2.0 PDS_TONAME_EQ_TOLOCAL_SHORT Short body with To: name matches everything in local email 2.0 SPOOFED_FREEMAIL No description available. --- Begin Message --- Hi, I've asked in the forum about support for multiple displays when using i.MX8 and EGLFS, and they suggested to ask here: https://forum.qt.io/topic/106976/multiple-displays-support-on-i-mx8-and-eglfs So my question is: which level of support for multiple displays does the "eglfs_viv" integration have when running on a i.MX8? Thank you, Diego --- End Message --- ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Expected event execution order in this multi-thread application
>> - E2 is sitting in the event queue of T1 at the second position but gets >> never executed. Use combination of QCoreApplication::sendPostedEvents(); QCoreApplication::processEvents(); . пн, 30 сент. 2019 г. в 11:37, Rainer Wiesenfarth < rainer_wiesenfa...@trimble.com>: > On Mon, Sep 30, 2019 at 9:26 AM Thiago Macieira > wrote: > >> [...] Anyway, this is when you should use processEvents(): never. >> > > ...which would be a perfect reason to at least mark it as obsolete in Qt 6? > > I strongly second Thiago's recommendation: processEvents() usually > introduces more problems than it solves. > > -- > Software Engineer | Trimble Imaging Division > Rotebühlstraße 81 | 70178 Stuttgart | Germany > Office +49 711 22881 0 | Fax +49 711 22881 11 > http://www.trimble.com/imaging/ | http://www.inpho.de/ > > Trimble Germany GmbH, Am Prime Parc 11, 65479 Raunheim > Eingetragen beim Amtsgericht Darmstadt unter HRB 83893, > Geschäftsführer: Dr. Frank Heimberg, Jürgen Kesper > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest > ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Expected event execution order in this multi-thread application
On Mon, Sep 30, 2019 at 9:26 AM Thiago Macieira wrote: > [...] Anyway, this is when you should use processEvents(): never. > ...which would be a perfect reason to at least mark it as obsolete in Qt 6? I strongly second Thiago's recommendation: processEvents() usually introduces more problems than it solves. -- Software Engineer | Trimble Imaging Division Rotebühlstraße 81 | 70178 Stuttgart | Germany Office +49 711 22881 0 | Fax +49 711 22881 11 http://www.trimble.com/imaging/ | http://www.inpho.de/ Trimble Germany GmbH, Am Prime Parc 11, 65479 Raunheim Eingetragen beim Amtsgericht Darmstadt unter HRB 83893, Geschäftsführer: Dr. Frank Heimberg, Jürgen Kesper ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Expected event execution order in this multi-thread application
>> - Thread T1 is handling an event E1 >> - Thread T1 sends E3 to itself (queued connection) >> - Thread T2 sends an event E2 to T1 (queued connection) >> - Thread T1 handles E3 after completing E1. >> - Thread T1 while handling E3 calls QCoreApplication::processEvents() >> periodically >> - E2 is sitting in the event queue of T1 at the second position but gets >> never executed. > > How do you know that? Because I attached a debugger and stopped T1 during QCoreApplication::processEvents(). I can see E3 (the one that the thread is currently processing) in postEventList at index 0 and E2 at index 1. That's it. From there I see the following call chain QEventDispatcherGlib::processEvents() followed by emit awake() because canWait is false. I haven't traced it further. The signal emission doesn't have any consequence in the event loop though. > There's still a lack of synchronisation between T1 > calling processEvents() and T2 posting the event. What if the event was > posted > after you called it? Then I would expect the event to be handled by the next invocation of QCoreApplication::processEvents(). > Anyway, DON'T use processEvents(). Redesign your code. It's unfortunately QScriptEngine which calls this method, triggered by a periodic timer. The application is Qbs and it is blackboxtest::concurrentExecution which triggers that behavior. It processes a long-running script that expects a file to appear in the file system produced by another thread. But for this to happen, the current execution thread needs to handle events. The testcase usually behaves as expected, but in rare cases it doesn't and that is what I am currently investigating. https://bugreports.qt.io/browse/QBS-1499 Before I suggest an action, I want to understand the error. >> Sure, but I don't see a synchronization problem as long if >> QCoreApplication::processEvents() would do what the documentation says: >> executing pending events in the current thread. Am I misunderstanding >> something? > > ALREADY pending events. Yeah, sure, but I have already said that QCoreApplication::processEvents() is called periodically. I don't care on which invocation E2 is handled. > Anyway, this is when you should use processEvents(): never. It is a public API and it is not marked as deprecated. If the function does not behave as documented, then either the documentation is wrong or the implementation has a bug or I am using it the wrong way. I don't think the latter is the case, but maybe I need a minimal test case to prove that. Best regards Richard ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Qt Creator: specify default project to run in .pro file?
> -Original Message- > From: Interest On Behalf Of Alexander > Dyagilev > Sent: Monday, 30 September 2019 5:18 AM > To: Qt Project > Subject: [Interest] Qt Creator: specify default project to run in .pro file? > > Hello, > > My project contains several executable projects. One of them is main GUI > application and I want it to be set as to run by default. Now Qt Creator by > default assigns another one and I have to switch to main GUI project > manually for every new platform / new solution load. > > Is it possible? You could try putting CONFIG += qtc_runnable in the project that you want to run by default. https://doc.qt.io/qtcreator/creator-run-settings.html#creating-run-configurations-for-subprojects I seem to remember that working, but the after reading the description in the docs, I'm not so sure. > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Expected event execution order in this multi-thread application
On Sunday, 29 September 2019 22:51:57 PDT Richard Weickelt wrote: > After debugging a bit, I come to realize that my above description is > incorrect. > > - Thread T1 is handling an event E1 > - Thread T1 sends E3 to itself (queued connection) > - Thread T2 sends an event E2 to T1 (queued connection) > - Thread T1 handles E3 after completing E1. > - Thread T1 while handling E3 calls QCoreApplication::processEvents() > periodically > - E2 is sitting in the event queue of T1 at the second position but gets > never executed. How do you know that? There's still a lack of synchronisation between T1 calling processEvents() and T2 posting the event. What if the event was posted after you called it? Anyway, DON'T use processEvents(). Redesign your code. > I think my question was misleading. I am not so much interested in the order > of arrival, but rather in "when" E2 gets executed by T1. I am fine with any > arrival order and start of execution as long as > QCoreApplication::processEvents() executes pending events while E3 is > running. But that is not the case in above scenario. E2 is such a pending > event, yet it doesn't get executed. processEvents() does not process events posted after it started. It may want for new timers and socket notifications, but not for new events. > > The solution is to take a look at your threading code and see if you need > > a > > synchronisation. > > Sure, but I don't see a synchronization problem as long if > QCoreApplication::processEvents() would do what the documentation says: > executing pending events in the current thread. Am I misunderstanding > something? ALREADY pending events. Anyway, this is when you should use processEvents(): never. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
