0
votes

Qt doc:

If no event loop is running, events won't be delivered to the object. For example, if you create a QTimer object in a thread but never call exec(), the QTimer will never emit its timeout() signal. Calling deleteLater() won't work either. (These restrictions apply to the main thread as well.)

Does this mean that signal void QTimer::timeout() will also issue a QEvent?
If so, where does the Qt doc state this?

1
QTimer and QTimerEvent are two different ways of using timers in Qt. See the Qt doc for more information. QTimer uses signal/slot communication while QTimerEvent (created by QObject::startTimer and handled by QObject::timerEvent() or and event filter) are, well, events. But both require an event loop in the current thread.cbuchart

1 Answers

0
votes

where does the Qt doc state this?

Nowhere, because it shouldn't matter to the user of QTimer. The timer event is an implementation detail. It is delivered to the timer object itself, so you'd really have to go out of your way to intercept it. Here's how QTimer works:

class QTimer : public QObject {
  Q_TIMER
  QBasicTimer m_timer;
protected:
  void timerEvent(QTimerEvent * ev) override {
    if (ev->timerId() == m_timer.timerId())
      emit timeout();
  }
  /*...*/
};

If you think about it, there's no way of emitting any signals without running the code that emits the signals, and the only way to safely run such code that emits things asynchronously is to code for run-to-completion chunks that cede control to the event loop at every opportunity. The event loop is notified by the platform that a timer has timed out, and emits a signal right then. You'd be in deep trouble if Qt issued signals such as timer timeouts from intrusive asynchronous callbacks like Unix signals: just read about how few things you can do while in a signal handler - it'd be no different than an interrupt handler.