3

I'm wondering if a queued event in Qt is the same for event and for signals (which are not emitted from the same thread as the received slot, and therefore enqueued.)

So to be clear, do we have:

  • one queue for event
  • one queue for signal (which can't be executed directly, due to emit/slot in different threads)

or do we have

  • one queue for event and signal
Guillaume Paris
  • 10,303
  • 14
  • 70
  • 145
  • 1
    does this help? http://stackoverflow.com/questions/638251/how-to-emit-cross-thread-signal-in-qt – INS Dec 13 '11 at 13:48

1 Answers1

3

There is a single queue. invokeMethod() produces a QEvent which is a "QMetaCallEvent". It's event index 43, and you can see it here as QEvent::MetaCall:

http://doc.qt.io/qt-5/qevent.html#Type-enum

It is put into the queue in qmetaobject.cpp...where "invoking" triggers a call to QApplication's postEvent. Here is the link to that line at the time of writing at the time of updating broken gitorious links

/src/corelib/kernel/qmetaobject.cpp line 2228

There is no "priority" parameter passed, so signal/slot calls will always be Qt::NormalEventPriority.

The details of this are not really contractually laid out too well in the documentation, so I'd be cautious of assuming too much about the behavior on every platform and version in the future. If you need a rigorous contract for the ordering of event processing in some part of your program, you might be best off coding your own explicit protocol.