Order of slots execution

Pablo J. Rogina

@Absurd said in Order of slots execution:

Just thought it'll be easier/more readable/modular that way...

Yes, it will but as mentioned previously relying on execution order is not a good approach, and it might also indicate that the two methods are indeed very likely to be just one?

MrShawn

In general I also think it is better to program with signals and slots in an asynchronous method, that is to say never write code that assumes signals/slots are emitted / executed in a specific order. Instead if you need slots to run in a specific order then they should call their chain slots with a signal of their own or return a signal back to the original caller so that it knows it can then emit the next signal to trigger the next slot.

SGaist

Hi,

@Absurd said in Order of slots execution:

@JKSH said in Order of slots execution:

Could you merge both slots into one function instead?

I probably can.
Just thought it'll be easier/more readable/modular that way...

Thanks!

How are these slots related to each other ?
Are they reused somewhere else ?
How did you split the code ?

Absurd

Thanks for anyone who tried to help.
I decided to go with one signal and one slot. I merge the two slots into one.

Absurd

Follow up question:
Do slots-that-invoked-due-to-signal run synchronously to main-thread of execution?

For example, in my code example above:
Am I guaranteed that slotA() will be executed only after signalsEmitter() has finished execution?

(reason I'm asking is that I experience some weird behavior, which I think is a result of some race...)

Thanks.

JKSH

@Absurd said in Order of slots execution:

Do slots-that-invoked-due-to-signal run synchronously to main-thread of execution?

For example, in my code example above:
Am I guaranteed that slotA() will be executed only after signalsEmitter() has finished execution?

No.

If the sender and receiver live in the same thread, then you will have a Qt::DirectConnection by default. In this scenario, Emitting a signal is the same as calling all connected slots. This means the signal emission blocks until all the slots have finished executing.

So in your example above, the order of execution is like this:

void objectA::signalsEmitter() {
   ...
    // emit signalA(x);
    objectB->slotA(x);

    // emit signalB(y);
    objectB->slotB(y);
   ...
}

signalsEmitter() returns AFTER your slots have finished executing.

aha_1980

@Absurd,

no that assumption is not guaranteed.

If both objects are in the same thread, the slot is run immediately on emit (like a functoin call).

Otherwise, it will run anytime after emit.

Absurd

@JKSH , @aha_1980
Just to make sure I understand... (and sorry if it sounds like a stupid question, as I don't have any experience with multi-threading programs...)
Although a single object can be instantiated by only one thread, it can be accessed by many, so what's the meaning behind "objects that live in the same thread"?

aha_1980

@Absurd it's meant, if your objects are both in the same or in different threads.

Accessing objects from different threads is ... complicated. but with signals and slots its super-easy.

JKSH

@Absurd said in Order of slots execution:

what's the meaning behind "objects that live in the same thread"?

This concept applies to QObjects and the signal-slot mechanism. In simple terms, when we say that a QObject lives in Thread X, we mean that the QObject's slots will run in Thread X.

If your program is single-threaded, then you don't need to worry about this concept. If you want to learn more, read http://doc.qt.io/qt-5/qobject.html#thread-affinity.

Although a single object can be instantiated by only one thread, it can be accessed by many,

That is technically true, but there are dangers in allowing an object to be accessed from multiple threads. You'll need to take extra steps to make your object thread-safe.

Just to make sure I understand... (and sorry if it sounds like a stupid question, as I don't have any experience with multi-threading programs...)

It's a perfectly valid question :) We all ask questions to deepen our understanding! We're happy to answer your questions.