Timer::stopTimer documentation clarification please

General JUCE discussion
1

In the docs for this method it says...

"If this is called from a different thread, any callbacks that may be currently executing may be allowed to finish before the method returns."

Does the "may" mean will or might - if the latter any sense of the criteria for this to happen.

Cheers

2

Yep, that was quite badly written! Will update it to this:

 

    /** Stops the timer.
        No more timer callbacks will be triggered after this method returns.
        Note that if you call this from a background thread at the same time as the
        message-thread is already in mid-callback, then it won't wait for the current
        callback to finish, but it will cancel any future callbacks.
    */
3

Ok cool - thanks for clarification.

Is there any recommended way of waiting for callbacks to finish by any chance...

4

You could put your own mutex around whatever shared data the callback is using.

Or you could you your stopTimer call inside a MessageManagerLock. Be careful with those, though, they can cause nasty deadlocks if you use them wrong.

5

/** Stops the timer. No more timer callbacks will be triggered after this method returns. Note that if you call this from a background thread at the same time as the message-thread is already in mid-callback, then it won't wait for the current callback to finish, but it will cancel any future callbacks. */

So it won't wait  for the current callback to finish, but the current callback will finish right ?


 

6

It will finish unless you put an infinite loop in it!

7

Perhaps it could be worded like "the callback will still finish, but this method will not wait for it to finish" 

8

Ok.. that's already how the sentence sounds to me, but if it's confusing people then I can make it clearer..