Timer may dispatch even after being disabled (not removed) or reconfigured
The following discussion from !45 (merged) should be addressed:
// Removing a timer always prevents its callback from // being called ... wl_event_source_remove(context->timers); // ... but disarming or rescheduling a timer does not, // (in the case where the modified timers had already expired // as of when `wl_event_loop_dispatch` was called.)
This is quite interesting behavior btw. We don't seem to document that anywhere in the API. It should be, because I think it is surprising. I read the old timer and event loop code, and indeed this seems to be how it works. To me it is a design mistake, but I'm not sure we can change it anymore.
I think if a timer is disabled instead of removed, I would still intuitively expect it to not call the callback anymore. It is kind of a race, yes, but if there are two event handlers competing, one of them being this timer, and the other fires first, the other one might change state such that calling the timer handler does not work anymore. I suppose it is not unusual to want to keep the timer around disabled until it is needed again.
Roughly the same applies when a timer is updated to fire later than originally due to some other event. It doesn't matter which event actually happened first, it is the dispatch ordering that matters. Again, the handler for another event might reconfigure the timer, and I wouldn't expect the timer to dispatch according to its old state afterwards.
I have a feeling we would need to review all timer uses in Weston and check that they are safe against this... quirk.
The very least we need the documentation to underline this behaviour, if we deem that we cannot change this behaviour.
- Is this behaviour desired?
- If not, can we change it?