|
|
On 5 Jul 2021, at 21:02, Albrecht Schlosser wrote:
>
> (1) Every call to Fl::add_timeout() or Fl::repeat_timeout() adds a timer entry to the internal timer queue. This queue is sorted by the timer's due time.
>
> (2) There's only one system timer, using the smallest delta value, i.e. the time of the first timer in the queue.
>
> (3) Whenever the timer triggers (or maybe more often) the event handling decrements the delta time of all timers.
>
> (4) All timers callbacks of expired timers are called.
>
> (5) A new timer with the shortest delay (which is always the first timer in the queue) is scheduled.
>
> (6) Wait for timer events...
>
> This is AFAICT done because the standard Unix timers can be interrupted and need to re-scheduled whenever such interrupts occur.
Also, since that design was created, it is possibly worth considering that the major desktop OS now tend to apply timer coalescing, at least to some extent, which would not have been the case in times past...
What this means is that the OS tries to shuffle as many timer-related events as possible into a smaller set of time slots, so that at each time slot it can execute “all” the pending events then sleep the CPU (or at least drop the CPU into a lower power state) and thus minimise power/heat and maximise battery life etc.
I don't know if that would affect how we think about this issue or not, though.
--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/42064247-9E8D-48B7-846F-E9BEDD261F81%40gmail.com.
[ Direct Link to Message ] | |
|
| |