FLTK logo

Re: [fltk.coredev] Re: 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 ]

Re: Re: RFC: unify timer callback handling on all platforms Manolo Jul 06, 2021  
 

Le mardi 6 juillet 2021 à 16:04:32 UTC+2, Albrecht Schlosser a écrit :
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).

The macOS FLTK platform uses a system timer: the event loop is made by calling a function that does "wait until an event arrives",
and Fl::add_timeout creates a system object that makes the waiting function run the timer cb when the delay has expired.

Is it correct that this is one distinct system timer per timer queue entry?
Yes, one system timer per queue entry.


My idea was to also use a true system timer for the Wayland platform (but that could be for all Linux). Posix timers do that.
They trigger either a signal or a thread after a specified delay. With the thread approach, having the child thread call Fl::awake(cb, data)
allows the main thread to stop waiting and process the timeout cb.

Hmm, is this a necessary change for the Wayland platform, or do you want to do it because you find the current implementation "awkward"?
No. The X11 implementation works with Wayland just as well as with X11.

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.

As written above,  the X11 approach uses the fd through which all X11 data arrives and the poll/select call on this fd to simulate
timeout events: it reduces the max waiting time of the poll/select call. Is your idea to change the organization of the event loop
of other platforms (namely macOS) and have it wait for GUI events for a time determined by the next scheduled timeout?

I can't answer this question with yes or no.

My basic idea is to unify (and therefore simplify) the timer event handling on all platforms. I've seen IMHO too much platform specific code to handle timer events. The more platforms we add, the more platform specific code we need to maintain.

My goal is to do as much as possible in platform independent code. This platform independent code would schedule timer events by adding them to the timer event queue - in my model the Unix/Linux code would be a valid implementation. This could be done on all current and future platforms in a platform independent way. There would also be only one platform independent timer event processing function. This could be (like) the current  Unix/Linux implementation which decrements the timer delay of all timer events in the queue.

The only platform dependent code should be the scheduling of the timer event. This could be as it is now on Unix/Linux to reduce the select/poll timer to the next timer delay or to schedule exactly one system timer on each platform which would be the delta time to the next (first) timer event. The only requirement is that the resulting timer event would call the platform independent process_timer_event() function.

For further clarification: my model would allow to use the fd approach we're using now as well as POSIX timers and Windows or macOS timers as long as we're only scheduling one timer for all systems and we're doing the timer event processing in only one system independent function. This is basically what I want to achieve.

This would allow us to get the same behavior on all current and future platforms including the optimal "repeated timer delay correction" with the minimum of platform specific code. A nice side effect would be that porting to another platform would be simplified.
Good. I think I begin to understand more clearly what is your proposal. It requires to distinguish between timer queue entries and system timers
and to have only one system timer. I had not envisaged this before. That seems to allow to much reduce the platform-specific part of timer support.
I look forward your proposal.

--
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/af4ac075-8bcc-4003-8822-a163bd025ae0n%40googlegroups.com.
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'.