Signals and Slots, processing order
-
wrote on 29 Oct 2023, 08:05 last edited by SPlatten
Is there a way to ensure that a slot is processed last if they're are other slots connected to the same signal ?
I have a signal and slot connection and it seems that the processing order of the signals and slots is not in the order they were connected.
I need to ensure that one particular slot is always the last to be called.
-
Is there a way to ensure that a slot is processed last if they're are other slots connected to the same signal ?
I have a signal and slot connection and it seems that the processing order of the signals and slots is not in the order they were connected.
I need to ensure that one particular slot is always the last to be called.
@SPlatten said in Signals and Slots, processing order:
Is there a way to ensure that a slot is processed last if they're are other slots connected to the same signal ?
No
I need to ensure that one particular slot is always the last to be called.
Then your design is flawed.
-
@SPlatten said in Signals and Slots, processing order:
Is there a way to ensure that a slot is processed last if they're are other slots connected to the same signal ?
No
I need to ensure that one particular slot is always the last to be called.
Then your design is flawed.
wrote on 29 Oct 2023, 08:09 last edited by@Christian-Ehrlicher , why do you say that? I want / need an action to be performed last, how can you say the design is flawed when you know little except what I have said ?
-
Is there a way to ensure that a slot is processed last if they're are other slots connected to the same signal ?
I have a signal and slot connection and it seems that the processing order of the signals and slots is not in the order they were connected.
I need to ensure that one particular slot is always the last to be called.
wrote on 29 Oct 2023, 11:49 last edited by JonBIs there a way to ensure that a slot is processed last if they're are other slots connected to the same signal ?
It should be last one connected.
I have a signal and slot connection and it seems that the processing order of the signals and slots is not in the order they were connected.
I believe it is done in the order of connection. Minimal example?
I need to ensure that one particular slot is always the last to be called.
- Connect it last per above.
- If you don't trust that, or it doesn't work like that, or it's too hard to connect in particular order, just write your own "dispatcher", i.e. connect signal to your dispatcher as lone slot, "connect" (your connect, not Qt's) original slots to your dispatcher only, implement desired "queue" (e.g. such-and-such a slot to be called last) in your dispatcher so that is the order you call things from your "connections" to this dispatcher.
-
Is there a way to ensure that a slot is processed last if they're are other slots connected to the same signal ?
It should be last one connected.
I have a signal and slot connection and it seems that the processing order of the signals and slots is not in the order they were connected.
I believe it is done in the order of connection. Minimal example?
I need to ensure that one particular slot is always the last to be called.
- Connect it last per above.
- If you don't trust that, or it doesn't work like that, or it's too hard to connect in particular order, just write your own "dispatcher", i.e. connect signal to your dispatcher as lone slot, "connect" (your connect, not Qt's) original slots to your dispatcher only, implement desired "queue" (e.g. such-and-such a slot to be called last) in your dispatcher so that is the order you call things from your "connections" to this dispatcher.
@JonB said in Signals and Slots, processing order:
I believe it is done in the order of connection.
It is, and also documented nowaydays that it is so iirc.
But this does not solve the design flaw :) -
Is there a way to ensure that a slot is processed last if they're are other slots connected to the same signal ?
It should be last one connected.
I have a signal and slot connection and it seems that the processing order of the signals and slots is not in the order they were connected.
I believe it is done in the order of connection. Minimal example?
I need to ensure that one particular slot is always the last to be called.
- Connect it last per above.
- If you don't trust that, or it doesn't work like that, or it's too hard to connect in particular order, just write your own "dispatcher", i.e. connect signal to your dispatcher as lone slot, "connect" (your connect, not Qt's) original slots to your dispatcher only, implement desired "queue" (e.g. such-and-such a slot to be called last) in your dispatcher so that is the order you call things from your "connections" to this dispatcher.
@JonB said in Signals and Slots, processing order:
I believe it is done in the order of connection. Minimal example?
Across thread boundaries enqueueing the event is done in a non-deterministic way (which is also the only way). This is also why it's absurd to require a specific order of slot call invocations, which is what @Christian-Ehrlicher alluded to.
What one can (reliably) do is to model a state machine, and push the state as calls come. Thus, allowing you to know what are the possible transitions. Incidentally, this is what people have been doing for ages for anything async, where call order is not strictly defined (which is most things - GUI, network, etc).
-
@JonB said in Signals and Slots, processing order:
I believe it is done in the order of connection.
It is, and also documented nowaydays that it is so iirc.
But this does not solve the design flaw :)wrote on 30 Oct 2023, 08:16 last edited by@Christian-Ehrlicher said in Signals and Slots, processing order:
I believe it is done in the order of connection.
It is, and also documented nowaydays that it is so iirc.
Have you any pointers where it is documented? I've had situations, at least with Qt 5, where it was not in order. It might have been from one thread to one other, but definitely not multiple threads. If there is an order, I would at least also expect that even across thread borders within one thread they are ordered (as the signaling thread cannot overtake itself).
-
@Christian-Ehrlicher said in Signals and Slots, processing order:
I believe it is done in the order of connection.
It is, and also documented nowaydays that it is so iirc.
Have you any pointers where it is documented? I've had situations, at least with Qt 5, where it was not in order. It might have been from one thread to one other, but definitely not multiple threads. If there is an order, I would at least also expect that even across thread borders within one thread they are ordered (as the signaling thread cannot overtake itself).
@SimonSchroeder It was not documented in Qt5, then a discussion on the ml and then this was added: https://doc.qt.io/qt-6/signalsandslots.html#signals (but it seems to be backported to Qt5).
But I must admit it's a little bit to generic as it does not cover the queued-connection case where it's not defined. Even though it's on-order when passing all from one to another thread since the events are added to the receivers event queue.
7/8