What does "control returns to the event loop of the receiver's thread" mean?
-
Hello,
I'm a little bit confused by the queued connection description. Here it is:
"The slot is invoked when control returns to the event loop of the receiver's thread. The slot is executed in the receiver's thread."
I don't understand what it mean. Does that mean that the slot is invoked directly after the first return that occurred in the thread? If I'm wrong, what is this "control returns to the event loop"?
-
In short, here is how even loop works:
- It is an infinite loop (think
for (;;)
). - For each iteration, it looks at events that have been queued, picks one and executes it.
- Events here are: every
QEvent*
subclass, some signal emissions.
A single CPU core can do only one thing at a time (well, that's a massive simplification, but let's go with it for a while). So when it processes some event, it cannot process any other until current operation stops (function ends) and the next iteration of the event loop happens. This is exactly what this documentation refers to: your calling thread will send the signal, receiving thread will queue it - but even if queue is empty it may take a while until current operation in receiving thread is being handled.
after the first return that occurred in the thread?
You could say that, yes. Although it's not entirely correct, because you can have nested function calls, so control will return to event loop after the last function returns. And there may be other signals and events already queued so your call might need to wait a bit longer. But in a simple case yes, your slot will be called after current function (in receiving thread) will finish. Wait time is usually milliseconds tops.
Also an important point here: if you are calculating something "heavy" in that thread (some long calculation is taking place, or a huge loop is executing) all queued events will be waiting.
- It is an infinite loop (think
-
Most of Qt applications could be described like this:
- you connect signals of Qt objects to your slots
- you inherit some Qt classes and override their virtual methods, including various
xxxEvent
methods - after some initial setup when objects are constructed and connections are done, you just wait when Qt will call one of your slots or overridden methods
When Qt calls into your code, it may invoke many other functions, however there is a moment when that very slot or method called by Qt finishes execution and control returns back to Qt. That's almost the place where control returns to event loop of current thread (it may actually return after Qt executes a bit of its own code and starts waiting for more events).
There is also a way to return control to event loop explictily by calling
processEvents
-
Well, thank you guys, this is much more clear, but I am not sure to understand what sierdzio said about the infinite loop, which is exactly by what I am interested, so here is the problems that I have:
I need to deal with a master-slave communication where the communication is done through a TTL serial port (one wire doing both the RX and the TX). I need to make sure that, during a loop, a portion of the code is uninterrupted until it receive its answer. Example:
void function_loop() { while(1) { for(int 1(0); i<=X; i++) { int info( not_a_QSerialPort.askIntInfo());//must be uninterrupted function_that_use_info( info); { { {
Is there is a way to make sure that the while loop can be interrupted, but not the specified code section in particular without modifying any of the already implemented code? The not_a_QSerialPort is, in reality, a class (that inherit from QObject) containing a protocol and port handler (that are not programmed with Qt).
-
@Factao said in What does "control returns to the event loop of the receiver's thread" mean?:
infinite loop
@sierdzio just means that the event loop runs as long as it is not stopped.
Your whole while loop will not be interrupted as long as you do not call https://doc.qt.io/qt-5/qcoreapplication.html#processEvents
Implementing such long lasting loops in main thread in event driven frameworks like Qt is a bad idea as it blocks the thread and the UI does not react on user input. It is betther to move such code in another thread, or if there is Qt functionality for that (like serial port) use the assynchronous nature of Qt APIs.