FLTK logo

[fltk.coredev] RFC: unify timer callback handling on all platforms

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 All Forums  |  Back to fltk.coredev  ]
 
Previous Message ]New Message | Reply ]Next Message ]

RFC: unify timer callback handling on all platforms Albrecht Schlosser Jul 05, 2021  
  I'm writing this because ...

On 7/5/21 3:09 PM Manolo wrote in thread "About mixing Fl::awake(Fl_Awake_Handler, void*) and Fl::awake(void*)":

I'm asking because I'm exploring the use of Posix timers to implement Fl::add_timeout() 
for the Wayland platform (see the timer_create() and timer_settime() functions).
These functions allow to trigger the timer either as a signal or starting a thread.
I've chosen the thread option, and have the thread call Fl::awake(cb, data)
so that the timer's callback gets then called by the main thread in its event loop.

@Manolo: Before you dive too deep into a specific implementation for Wayland I'd like to share some thoughts I'm having since some time now to unify the timer handling on all platforms. I believe that the Linux timer implementation is superior to the Windows and maybe also the macOS implementation. The Linux timer implementation works like this (maybe over-simplified):

(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.

The benefit of this approach is as described in Fl::repeat_timer() docs: if the call to Fl::repeat_timer() is done "late" it can be corrected by the delay and the overall timer sequence of repeated timers is more accurate than on other platforms.

On the Windows platform we're (AFAICT) using one system timer per Fl::add/repeat_timer() call. The Windows timer events are less accurate anyway, but a change as designed for Unix/Linux could probably contribute to more accuracy of repeated timer events because the correction of timer delay as on Unix/Linux could work better (it does not currently on Windows).

I know less about the macOS platform, but I know for sure that the timer handling is different. There are inconsistencies WRT Unix/Linux/Windows on the user visible level (which I intend to demonstrate with a test program anyway) but which are too difficult (and OT now).

That all said: I hope that the Wayland implementation would be basically like the Unix/Linux timer queue handling so we can easily unify all platforms.

More about the unification: I'm thinking of a platform independent timer queue where Fl::add_timeout() and friends would be platform independent. They would add an Fl_Timeout_XX object to the timer queue which may contain platform specific timer data (or not?). Triggering the timeout would then, as always, be done by the system, the timer queue handling would still be platform independent, as well as calling the callbacks etc.. The more I think about it, the more I believe that only the scheduling of this single timer event would be a platform dependent (i.e. system driver) function.

Comments welcome, particularly from Manolo but also from other devs. If I'm not missing anything (are there any drawbacks?) I could start soon to develop a new timeout handling model which does all of this as described.

--
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/7bf6c876-8c0e-6ad7-a31f-834276e3ee50%40online.de.
Direct Link to Message ]
 
     
Previous Message ]New Message | Reply ]Next Message ]
 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.