Timer: thread problem or just the imagination?


#1

Is it possible for Timer::timerCallback() to get called even after calling Timer::stopTimer()? Looking over juce_Timer.cpp, which is somewhat complex, it seems that it is possible for the timer message to go into the message queue (CallTimersMessage), and then Timer::stopTimer can get called. The CallTimersMessage will still get processed.

So is this possible? Or do the atomic booleans / memory barriers prevent the message from actually calling the Timer::timerCallback()??


#2

Yes, I think it’s quite possible that stopTimer will return before the message thread has completed a callback… That’s not really a bug, just not something that the class guarantees.

Although it’s safe to call stopTimer from another thread, and doing so will stop the timer, it won’t attempt to synchronise with the message thread - if doing so is important to your program, then you should use a MessageManagerLock around the stopTimer call, or call it from the message thread.


#3

[quote=“jules”]Yes, I think it’s quite possible that stopTimer will return before the message thread has completed a callback… That’s not really a bug, just not something that the class guarantees.

Although it’s safe to call stopTimer from another thread, and doing so will stop the timer, it won’t attempt to synchronise with the message thread - if doing so is important to your program, then you should use a MessageManagerLock around the stopTimer call, or call it from the message thread.[/quote]

Well, I’m calling stopTimer() from the message thread. This is in the docs for stopTimer():

So is it possible that when I call stopTimer, there is already a callback in the message queue, and I will still see timerCallback()?

I’m guessing no, because stopTimer() should remove the timer from the list of timers, and then callTimers() will not see the removed timer.


#4

Ok in that case, the timerCallback will definitely not be called again after you’ve called stopTimer!


#5

BTW there’s still a bug in the Timer I once noticed on OSX on a crappy iBook G4. It seems like if there’s heavy CPU load, some Timers fail to get called. I noticed it because some animations would stop while other Timer-based stuff would still work. Back then, I replaced JUCE’s Timer with the OSX system Timer, and it magically worked.


#6

Was this with the latest version?

The thing that sounds a bit wrong to me is that there’s only one timer thread, which only sends a single message - if the thread or message was blocked somehow, then ALL timers would fail, not just some of them. But if you’re talking about an older version, it might have been different.