Important: Please read the Qt Code of Conduct -

In which order are triggered the slots that are connected to the same signal?

  • Hi,
    I'm just wondering if Qt defines the order of trigger of the slots that are connected to the same signal?
    Especially if some slots lives in the same thread and are Queued.
    Would it be by order of the creation of the connection or is it something random?
    Is it the same with DirectConnection?

  • If you are depending on strict ordering when you have threads, it's sort of the wrong question to be asking. But if all connections are the same type then they should all be invoked in the same order they were connected.

  • Well I'm talking within the same thread, I'd like to know if there is a strict ordering.
    I know it could be some kind of bad design to rely on that but I'm wondering internally how it is working and if we could use it.
    I've two active objects running on a Main thread that are connected to a same signal received from other threads.
    Would Qt insure that one would be triggered before the other? Could we modify this order?

  • I don't think it's safe to rely upon the behaviour you seek. You should strive to think of the signals as asyncronous, even if they are not totally so.

  • Although I tend to agree with @Kent-Dorfman that it may not be "advisable" to rely on this behaviour, nonetheless Qt docs do explicitly state

    If several slots are connected to one signal, the slots will be executed one after the other, in the order they have been connected, when the signal is emitted.

    and later on:

    If on the other hand you want to call two different error functions when the number overflows, simply connect the signal to two different slots. Qt will call both (in the order they were connected).

    I would guess that having been designed and written like this, Qt will likely to stick to it.

    And, no, you cannot change that order --- other than by disconnecting and reconnecting slots into desired order. Or, you'd have to attach just one "super-slot" to the signal, and have that run as a "dispatcher" for other "slots" in desired order --- which would mean altering your calling code for setting up slots.

  • @JonB
    ok thanks, good to know. I didn't go read again the signal/slot page before posting my question, I guess I should have...

    I also agree it is bad design to rely on that but you might do it by mistake. On my app this was the case, I've a signal connected to 2 slots, the main one is created in the constructor of my object so will be triggered first and in some condition it might trigger the destruction of the object.
    The second one was added later on for GUI purposes, to update a value, and I was getting a segfault sometimes, mainly by my customers, never on my environment (would have been too easy...) as I could use a slot using a dangling sender.

Log in to reply