Signal/Slot process order in function

[samdol]

Hi,

I have been always wondering about the order of signal/slot processing order.
For example,

class AA
{
    private: ...

    public: AA(){}
            funcAA()
            {
                funcAA1();
                emit funcAA1_finished_signal();
                funcAA2();
            }
}
class BB
{
   private: ...

   public: BB()
           {
                AA* aa = new AA;
                connect(aa, SIGNAL(funcAA1_finished_signal()), this, SLOT(funcBB()));
           }
   public slots:
           funcBB(){...}
}

If I run funcAA(), after finishing funcAA1(), does funcAA2() runs always after
funcBB() has finished? or if funcBB() takes too long time to finish, does funcAA2()
may start even before funcBB() finished?

[JonB]

@samdol
I'll probably turn out to be wrong, but I can't resist stating my understanding which is that: [Qt] signals are synchronous. funcAA1_finished_signal() does not return till any/all slot handlers have completed.

Right?

And also, BTW, I read somewhere yesterday that signal handlers (slots) are executed in the order they were connected (to the same signal). As in, that is guaranteed, as opposed to "the order of execution is undefined" which I had presumed would be the case.

[VRonin]

@JonB kinda right.

• if you use Qt::DirectConnection or if sender and receiver of the signal are in the same thread and the connecion is automatic
  • 'emit <signal>' will not return until all slots are executed.
• if you use Qt::QueuedConnection or if sender and receiver of the signal are in different threads and the connecion is automatic
  • 'emit <signal>' returns immediately and the slot is executed once control goes back to the event loop (or QCoreApplication::processEvents is called)
• if multiple slots are connected to the same signal, the order of slot execution is the same as the order of connection

[JonB]

@VRonin
I was only thinking of your cases #1 & #3. i.e. for #1 I don't have my own threads, so I was thinking only in single-thread context, where I understood them to be synchronous, as you confirm. That also applies to the OP's example.

I do have one question about your code & explanation. Please bear in mind that I only use Qt from Python, I don't have the C++ code or macros to look through to discover this for myself. With that in mind, I want to understand the root of the distinction between your cases #1 & #2.

You are saying "emit <signal> behaviour varies depending on sender/receiver being in same or different threads". Now, I believe I am correct in saying that in your C++ emit is a macro which expands to nothing at all. In which case in both cases the code simply expands to the function call in the source immediately after the emit. Since emit in itself does nothing at all in the code, how do you get that behavioural difference you describe? It's just a C function call, so it knows nothing about same or different threads?

[VRonin]

@JonB said in Signal/Slot process order in function:

how do you get that behavioural difference you describe?

That's the magic of moc. It gives a body to your signals that basically is an if to check the threads and if they are the same it calls the slots otherwise saves the argument and schedules an event to trigger the slots as soon as the event loop takes control

[JonB]

@VRonin
Ah ha! And what is/am I using moc if I am Python/PyQt?? :)

[samdol]

@VRonin
Thank you. It is quite clear to understand.