FLTK logo

Re: [fltk.coredev] About mixing Fl::awake(Fl_Awake_Handler, void*) and Fl::awake(void*)

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: About mixing Fl::awake(Fl_Awake_Handler, void*) and Fl::awake(void*) Albrecht Schlosser Jul 05, 2021  
 
On 7/5/21 3:09 PM Manolo wrote:

Does any fellow developer know why the FLTK threading doc states :
"Don't intermix use of Fl::awake(Fl_Awake_Handler cb, void* userdata) and Fl::awake(void* message) calls in the same program as they may interact unpredictably on some platforms" ?

Do these platforms include Linux?

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.

Despite the warning in the docs I believe that using Fl::awake(Fl_Awake_Handler cb, void* userdata) is always "on the safe side". As Ian wrote already, the warning may be from an older part of the docs.

I believe the warning is platform independent and the part "on some platforms" can probably be removed. I would add that Fl::awake(void* message) is always kinda unreliable but using Fl::awake(Fl_Awake_Handler cb, void* userdata) is always reliable as long as you don't use the same userdata pointer during the lifetime of such an Fl::awake() request. With "lifetime" I mean the time from writing to the memory pointed to by userdata until it is processed by the awake handler. This is the essential part.

The docs of Fl::awake(void* message) say: "The default message handler saves the last message which can be accessed using the Fl::thread_message() function." This means that there is only one (likely static) storage location which will be overwritten if you call Fl::awake(void* message) more frequently than the awake call can be serviced. This will drop all intermediate messages and only the last message can ever be retrieved by the user program with Fl::thread_message(). Hence, the user program is responsible for not calling Fl::awake(void* message) more often than can be serviced by the FLTK main loop.

Note: I'm currently not able to verify this in the source code, but I believe this is the case.

If you add to this load by using Fl::awake(void* message) internally this would increase the load and unpredictable behavior would be the result.

However, if you only use Fl::awake(Fl_Awake_Handler cb, void* userdata) with its specific handler and userdata I don't think that there would be a conflict with user code, even if the user program used Fl::awake(void* message).

The problem with mixing both types of calls is maybe caused by potentially inverting the order of events, hence this should always be avoided, but if since the timer callbacks would likely not be related to any user code ... it might not effect the user code at all. Hopefully.

--
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/ffd0b794-0cca-37ba-d9b6-a723ed35bc56%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'.