1
votes

I am developing a consequent program which is very sensitive to time (based on delayed video streams), and since I'm not sure about how the signals and slots are implemented within Qt, I don't know when they are executed. Are they really executed in real time like callbacks would do, or are they processed before the next iteration of some kind of main loop?

My question would be about timers in particular: when a timer times out (which must be another thread), does it connect to the signal "instantaneously" (next instruction for example) nearly like an interrupt would do, or does it wait for the end of some loop?

Thanks for your insight,

Regards, Mister Mystère

4

4 Answers

3
votes

The last argument of QObject::connect is the connection type, which determines when slot will be executed. From the documentation:

  • Qt::AutoConnection - If the signal is emitted from a different thread than the receiving object, the signal is queued, behaving as Qt::QueuedConnection. Otherwise, the slot is invoked directly, behaving as Qt::DirectConnection. The type of connection is determined when the signal is emitted.

  • Qt::DirectConnection - The slot is invoked immediately, when the signal is emitted.

  • Qt::QueuedConnection - The slot is invoked when control returns to the event loop of the receiver's thread. The slot is executed in the receiver's thread.

  • Qt::BlockingQueuedConnection - Same as QueuedConnection, except the current thread blocks until the slot returns. This connection type should only be used where the emitter and receiver are in different threads.

2
votes

http://woboq.com/blog/how-qt-signals-slots-work.html

This seems to be quite a good description, though I haven't read it in detail.

Main point: there's direct connections and deferred connections. Direct connections are executed immediately.

2
votes

You can be quite sure the timer is not implemented in a different thread but instead is handled inside the event loop. Which means that when the timer fires, it is instantly connected. However the granularity for the timer to fire is your main problem.

If your timer were to emit the signal in a different thread, the slot would be called in the thread the receiving object belongs to. Which means that it would be deferred to the event loop. (As you can see it would not help to have the timer operate in a thread of its own.)

1
votes

And additionally in Qt5 you can set QTimer's precision: Qt::TimerType