<![CDATA[Threading and the main QT event loop.]]>I was hoping someone might give me some insight into how to better handle a situation I have. There are many time in this application where an event goes something like this:

  • User clicks button to do something

  • Signal is sent to business logic to ask threaded application to do that thing

  • Thing takes application x amount of time to do

  • Application responds with thing

While x amount of time passes the main event thread is locked. Currently, the application deals with this scenario by creating a busy wait and while waiting calls the QCoreApplication::processEvents(); which seems wrong. Can someone point me at some documentation for how other QT developers deal with situations like this? Perhaps they crafty use a mutex or simply ask the application to sleep? Perhaps a busy wait loop is the best option?

]]>https://forum.qt.io/topic/141617/threading-and-the-main-qt-event-loopRSS for NodeSat, 25 Apr 2026 09:31:55 GMTMon, 19 Dec 2022 19:19:00 GMT60<![CDATA[Reply to Threading and the main QT event loop. on Mon, 19 Dec 2022 20:06:22 GMT]]>Hi,

What is your exact architecture ?

If you have data exchange between two different applications you might want to consider using a model for the data and add a read-only entry to it while the creation is in progress with a status text explaining that. Then once the data is arrived make it read/write and show the actual data.

There should be no need to freeze your UI for that. If you need to actually wait for something without your users being able to interact with your application then a QProgressDialog will be a better solution.

]]>https://forum.qt.io/post/740831https://forum.qt.io/post/740831Mon, 19 Dec 2022 20:06:22 GMT<![CDATA[Reply to Threading and the main QT event loop. on Mon, 19 Dec 2022 20:06:22 GMT]]>Hi,

What is your exact architecture ?

If you have data exchange between two different applications you might want to consider using a model for the data and add a read-only entry to it while the creation is in progress with a status text explaining that. Then once the data is arrived make it read/write and show the actual data.

There should be no need to freeze your UI for that. If you need to actually wait for something without your users being able to interact with your application then a QProgressDialog will be a better solution.

]]>https://forum.qt.io/post/740831https://forum.qt.io/post/740831Mon, 19 Dec 2022 20:06:22 GMT<![CDATA[Reply to Threading and the main QT event loop. on Mon, 19 Dec 2022 19:56:40 GMT]]>@JonB Well, it depends on the instance but in general it's because the secondary application is the thing that is providing the real data that can be manipulated by the user. So for instance, let's say the user decides they want to create a job. The main application needs to ask the secondary application to first create the job (it handles remember the job exists) and then it feeds the primary application that job. So the user must wait for the job before they can start altering it or at least, that' s a simple way of handling it. Perhaps what should be done is to keep a copy of the job on the main application and then synchronize the data when it needs to be saved. Which may end up happening but in the meantime I was thinking perhaps the main application would be better served by a mutex or an atomic rather than using a busy wait loop to wait for the secondary application to finish processing.

]]>https://forum.qt.io/post/740829https://forum.qt.io/post/740829Mon, 19 Dec 2022 19:56:40 GMT<![CDATA[Reply to Threading and the main QT event loop. on Mon, 19 Dec 2022 19:35:43 GMT]]>@RobM
The intention of the Qt paradigm is that there ought be no "waiting". Since your business logic runs in its own thread it just sends a signal when it is "done" or "has something to say". I don't know why you busy wait + processEvents(). Why does your UI have to "wait" for anything?

]]>https://forum.qt.io/post/740819https://forum.qt.io/post/740819Mon, 19 Dec 2022 19:35:43 GMT