[Qt-interest] Do QTimer Race Conditions Exist

[Will Rutherdale (rutherw)]

Hi.

I am wondering about reliability of QTimer if it is used in certain
ways.  I am not questioning the internal robustness, but whether I have
to take certain precautions in using it.  I have an application where
getting it right is critical.  On the other hand I don't want to
over-engineer if it is not necessary.

The situation is like this.  Suppose I have a class criticalClass
derived from QObject with these slots:

    void slotFoo();
    void slotTimerResponse();

Also my class has a timer, used in singleshot mode:

    QTimer *timer_t_;

Also, a connect() has been done between timer_t_'s timeout() signal and
slotTimerResponse().  And suppose somewhere in the code I do this:

    timer_t_->start();

Now slotTimerResponse():

void criticalClass::slotTimerResponse()
{
    qCritical() << "Holy smokes what a HORRIBLE thing:  the timer has
expired.  Blowing up the whole system in despair!!!";
    // ...
}

Now somewhere else in the code, in slotFoo(), while the timer is active,
some expected event happens and the code does this:

    timer_t_->stop();

My question:  is it enough that I called stop() on the timer inside
slotFoo()?  I can see that the timer will stop running at that point,
but is it not also possible that, in parallel with that, while that slot
is active, the timer will emit its signal timeout().  If it does this,
then slotTimerResponse() is going to be executed next time around in the
event loop, even though I've already stopped the timer.

I read through the documentation (in Qt 4.5) and didn't see any clear
indication so far whether I have to be concerned about this situation.

Could someone please tell me about whether such a race condition can
exist:  is it possible for the timer to emit timeout() while a slot is
active that calls its stop() method?  Either tell me what you know or
point me in the direction of the relevant documentation if you can.

Any help would be appreciated.

-Will