Execution Flow (?)

[phil_n]

Hi all.

If I have a slot
on_actionOpen_File_triggered() and I put in it
emit mysignal()does the program continue to run 'out of' (not sure of proper terminology there) the slot or does it stop and wait for whatever is happening at the other end of the signal call? Say, mySiganlHandler() does some file processing.
I am thinking (IIRC) that in c++ a function doesn't get deleted (?) until all functions that were called by it have returned. Does the signal/slot system work the same way?

TIA

ps Thanks for all the help on my last query.

[anda_skoa]

A signal/slot connection within the same thread is basically like a direct function call.
So the emit will return when all slots connected to the signal have finished.

Cheers,
_

[d_stranz]

Normal signal / slot handling is synchronous; that is, all slots connected to a signal will be executed before control returns to the event loop. However, calling "emit mysignal()" in a slot puts a new event on the event queue, and does not cause immediate execution; it will be handled in turn once control returns to the event loop processor. If there are intervening events, these will (normally) be handled in the order posted. One exception to "normally" is paint events - if there are multiple paint events in the queue waiting to be processed, all but the last one will be discarded to avoid unnecessary painting.

I see that anda_skoa and I posted at about the same time, so I think he is saying the same thing I am.

[phil_n]

Thanks muchly.

[anda_skoa]

However, calling "emit mysignal()" in a slot puts a new event on the event queue, and does not cause immediate execution; it will be handled in turn once control returns to the event loop processor.

No.
Slot invocations are only asynchronous via events for Qt::QueuedConnection type connects(), e.g. used by cross-thread connections.

In a single threaded application, or when passing Qt::DirectConnection, emits always cause immediate execution of connected slots.

Cheers,
_

[phil_n]

You guys are getting a little over my head. But...could I say that when the 'executing thread' (in the single threaded application) reaches the emit it immediately jumps to a corresponding slot (governed by the rules of the queue) and then, when processing of that completes it returns to the line immediately following the emit statement - like I believe function calls do? This really has no bearing on what I am trying to do - it just crossed my mind as a curiosity.

TIA

[anda_skoa]

But...could I say that when the 'executing thread' (in the single threaded application) reaches the emit it immediately jumps to a corresponding slot (governed by the rules of the queue) and then, when processing of that completes it returns to the line immediately following the emit statement - like I believe function calls do?

Yes, this is exactly what happens.

Consider the signal emit to be a function call that simply iterates through the list of connections on that signal and calls each and every slot, one after the other.
When the list has been fully processed, the emit returns and execution continues at the next statement after the emit.

Cheers,
_

[d_stranz]

In a single threaded application, or when passing Qt:: DirectConnection, emits always cause immediate execution of connected slots.

Has this always been true? I am almost certain that in one of my apps where slots emitted signals, those signals were not handled until the slot exited. Perhaps the logic was complex enough that it only seemed that way when stepping through with the debugger.

Anyway, I stand corrected.

[anda_skoa]

Has this always been true?

Yes, I am pretty sure :-)

One thing that was also always basically true but not specified until Qt5 was that slots are execute in the order of connects.

Cheers,
_

[d_stranz]

Yes, I am pretty sure :-)

Well, now that I think about it, this would explain some of the behavior I observed. I implemented a kind of state machine based on the wrong assumption that signals would be queued, and couldn't understand why the same state methods would be executed multiple times when they should have been executed only once (based on the queued model).