4

I'm asking in a case where there is a lot of qt events queued in event engine. Does QTimer emit timeout() signal through event and will with queuedConnection to a slot create another event?

Anže
  • 181
  • 8

3 Answers3

3

The slots connected with Qt::DirectConnection will be called immediately when the QTimer::timeout signal is emitted by QTimer. If you use a queued connection, it will schedule an event to call the slot, which will be processed by the event loop. QTimer uses timerEvent to emit the timeout signal.

thuga
  • 12,601
  • 42
  • 52
  • Just a quick question: does this mean, when using `Qt::DirectConnection`, if the program is in the middle of running function `A` and the timeout signal is emitted, then execution of `A` is paused, the connected slot to timeout signal is executed, and after finishing executing it, the execution of `A` is resumed? Let's assume both `A`, timer and the connected slot belong to the same thread. – today Dec 08 '18 at 16:05
  • And is this the case with all connections of type `Qt::DirectConnection`? I am a little confused about this because everywhere I read, the **direct connection** is explained as "[the slot] will be called immediately when signal is emitted" or "it is like a function call". Actually, now I tested this on `QTimer`, but it seems that in this case the direct connection is like queued connection (both `QTimer` and the connected slot lived in the same thread in my test). I don't not understand their difference?! – today Dec 08 '18 at 21:28
  • 2
    @today That is because the `timeout` signal is emitted in the `timerEvent` event handler. This event is processed in the thread where the `QTimer` object lives in. And if function `A` is being executed, the application will wait for it to finish before starting to handle events. But if you create your timer in a different thread and use `Qt::DirectConnection`, then the slot will be executed immediately, regardless if `A` is being executed or not, and it will be executed in the thread where the timer lives in. So be careful. – thuga Dec 10 '18 at 09:45
1

No it is not queued connection by default unless it is running in a different thread. Therefore it is DirectConnection.

I would say that, in general, if you want to guarantee a sequential order of events you are better of using Qt::QueuedConnection with things like timers even when in the same thread so that the event goes onto the queue and is not just acted upon immidiatley - since this behaviour is some-what more like an "interrupt".

However if you really want the timer timeout() to be acted on immediately then use Qt::DirectConnection - I feel that you need to be more careful with this connection type in general (with things like timers which can trigger in the middle of other normal code).

Edit

By "normal code" I mean...well, see comments below:

code_fodder
  • 15,263
  • 17
  • 90
  • 167
  • 2
    Timers can't trigger in the middle of normal code. Timers are triggered by an event. That is why it needs an event loop to work. The docs state: [`For QTimer to work, you must have an event loop in your application; that is, you must call QCoreApplication::exec() somewhere. Timer events will be delivered only while the event loop is running.`](http://doc.qt.io/qt-5/timers.html). – thuga Jun 16 '16 at 07:25
  • I mean "normal" as in assuming running in a Qt program - therefore exec() will have run, sorry should not have assumed that - will correct that :) – code_fodder Jun 16 '16 at 07:27
  • 1
    So "in the middle of normal code" still means when the QCoreApplication gets free time to execute events and not during a function execution? – Anže Jun 16 '16 at 07:30
  • 2
    I don't see why would you have to be careful when using direct connection, as the slots are still only triggered when the application/thread goes back to the event loop. It basically acts like calling a slot with a queued connection, hence why people tend to use `QTimer::singleshot(0, object, &Object::slot);` to call functions "queuedly". – thuga Jun 16 '16 at 07:36
  • @thuga But this is what I am saying, you won't jump the queue by using QueuedConnection, you may if you use direct... – code_fodder Jun 16 '16 at 07:59
  • 1
    It is not really decided at connect time whether it uses queued or direct connection afaik. But always reevaluated at time of emission of signals. – Johannes Schaub - litb Jun 16 '16 at 08:13
  • What do you mean `jump the queue`? – thuga Jun 16 '16 at 08:21
  • 1
    @JohannesSchaub-litb That is true, at least for `Qt::AutoConnection`. Emitting a signal results in [`QMetaObject::activate` call, which checks the specified connection type](https://code.woboq.org/qt5/qtbase/src/corelib/kernel/qobject.cpp.html#3688). If `Qt::AutoConnection` was specified, it will check the thread affinities of the emitting and the receiving threads. If they are the same, it uses a direct connection, and if they are different, it uses a queued connection. – thuga Jun 16 '16 at 08:30
  • @thuga I mean, when the signal occurs it would get acted upon immediately instead of being added to the event queue. – code_fodder Jun 16 '16 at 08:44
  • But since it is called from the event queue, why does it matter? What will you gain by telling it to process the slot later? It is like having a slot you call with a queued connection, in which you only emit a signal which is connected to another slot via a queued connection. – thuga Jun 16 '16 at 08:51
0

When a QTimer times out, every Signal-Slot connection, which joins signal of this QTimer with an slot, fires this slot exactly one time.

Roland
  • 336
  • 2
  • 8