The general contract of a timer is that it will be called not-before its expiry time, and hopefully soon after. (In general, OS scheduling might mean that timer execution may be delayed according to the current load.)
However there is another question, about the order of execution of timers. The current implementation guarantees that timers are called in order of expiry time, but only to the implementation resolution. It makes no guarantees about the order of timer execution when several timers expire at the same Instant (within the lowest unit of time resolution used by the timer queue implementation).
The question is whether it would be worthwhile guaranteeing strict execution order by time, and then by submission order for timers with the same expiry Instant. The trouble is that time can stall for a while on the same value if Instant::now() skips backwards. Any code assuming that two timers started one after the other will execute in that order would be randomly broken by such a stall. If guaranteeing order doesn't add much overhead, then it would make things more deterministic, and make weird corner cases test the same each time. However, if the overhead would be too great, then the current behaviour needs to be documented.
The general contract of a timer is that it will be called not-before its expiry time, and hopefully soon after. (In general, OS scheduling might mean that timer execution may be delayed according to the current load.)
However there is another question, about the order of execution of timers. The current implementation guarantees that timers are called in order of expiry time, but only to the implementation resolution. It makes no guarantees about the order of timer execution when several timers expire at the same
Instant(within the lowest unit of time resolution used by the timer queue implementation).The question is whether it would be worthwhile guaranteeing strict execution order by time, and then by submission order for timers with the same expiry
Instant. The trouble is that time can stall for a while on the same value ifInstant::now()skips backwards. Any code assuming that two timers started one after the other will execute in that order would be randomly broken by such a stall. If guaranteeing order doesn't add much overhead, then it would make things more deterministic, and make weird corner cases test the same each time. However, if the overhead would be too great, then the current behaviour needs to be documented.