Timer::stopTimer documentation clarification please

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

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.
    */

Ok cool - thanks for clarification.

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

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.

/** 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 ?


 

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

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

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