Prevent Android timer from adding multiple callbacks

[hartez]

Description of Change

Android Timer can add callbacks to itself inside the Tick handler, resulting in an exponential explosion of Tick handlers. This adds a test for that situation and fixes it for Android.

Issues Fixed

Fixes #10257

[rachelkang]

what changed in API level 29?

[hartez]

The hasCallbacks() method did not exist until API 29.
https://developer.android.com/reference/android/os/Handler#hasCallbacks(java.lang.Runnable)

[rachelkang]

Could you help me understand how the Post, Stop, and callbacks logic all works?

[hartez]

Could you help me understand how the Post, Stop, and callbacks logic all works?

The point of the timer is to allow the developer to say "call this method in X milliseconds". The callback is the method they want to call. All of the platforms provide some sort built-in mechanism to do this; the IDispatcherTimer is an abstraction over those.

So you create a timer with a callback, and you set the interval (how long to wait before calling it). You can set it to repeat, or you can turn off repetition and it will run just once. Then you call Start() to get the timer ticking. When "interval" milliseconds have passed, the callback method will be called. If repetition is turned on, the timer will start counting down again. Otherwise, it will stop. You can also call Stop() at any time to stop the timer.

On Android, the built-in mechanism is called a Handler. A Handler manages a queue of messages/callbacks that are processed by a Looper (which just runs in a loop, checking to see if there's work to do). The Handler "posts" work items to the queue. It can post at the front of the queue (run immediately), at the end of the queue (get to this when you get to it), or at a specific time in the future (which is what the DispatcherTimer uses).

[rmarinho]

Do we need to worry about thread safety here?

[hartez]

I don't think so. Do you have a scenario where you think it would be a problem?

[rmarinho]

Two windows, but that will have 2 dispatchers right?

[mattleibow]

There may be the case where you use the timer from 2 threads that could cause issues. But I am not sure if the hasCallbacks method is itself thread safe...

[hartez]

Does this code need to be "thread safe"? None of our other DispatcherTimer implementations are.

And the only "thread safety" worry would be if someone decided to operate on the same DispatcherTimer from multiple threads. I would argue that if someone is going to do that, it's up to them to make sure that whatever thing they're doing is "thread safe". They wanna do something weird, they can add their own lock() statements.

(To be clear, this code is not "thread safe" in the sense that you could theoretically (it's really hard to do) have two threads attempting to call Start() at the same time and get a weird double-post behavior, and the pre-API 29 version would behave differently than the post-API 29 version. You could also cause problems by changing the values of IsRepeating and Interval from multiple threads, but that was a problem before this change and also with all of our other implementations of DispatcherTimer.)

[mattleibow]

I agree with all the above. We don't need to do locks ourselves.