Is Fl::check / Fl::wait / Fl::flush timeout safe?

[Gonzalo Garramuño]

We all know that Fl::check and similar functions are not thread safe. 
However, I found out that hidden in my code, I am calling Fl::check in a
loop from within a timeout (Fl::add_timeout / Fl::repeat_timeout) to
refresh my UI while the timeout does an expensive operation.

Is that safe?  Can Fl::check be called from within a timeout (ie.
recursively)?

Whatever the answer is, I would add it to the docs.

Thanks in advance, FLTK gurus.


--
Gonzalo Garramuño
ggar...@gmail.com

[Albrecht Schlosser]

On 7/22/26 22:18 Gonzalo Garramuño wrote:

We all know that Fl::check and similar functions are not thread safe.  However, I found out that hidden in my code, I am calling Fl::check in a loop from within a timeout (Fl::add_timeout / Fl::repeat_timeout) to refresh my UI while the timeout does an expensive operation.

First of all, the general answer is: the handling of a timeout *MUST* always be "short", for whatever measure of "short". I'm not sure if this is explicitly documented, but this is the same as for event handling and callbacks (which are always triggered by events). Otherwise the GUI can become unresponsive (as you may have noticed and therefore injected calls to Fl::check().

Having a loop and calling Fl::check() within a timeout breaks the above rule.

Is that safe?  Can Fl::check be called from within a timeout (ie. recursively)?

That's a hard question. I wrote the current implementation of our timeout handling, but to answer this - from a pure technical view - I need to look at the code. I can't say if "really bad things" (TM) could happen (such that timer queues could be broken? I guess not), but Im pretty sure that the timing of multiple timers and their order relative to the "long running timer" and particularly the precision of Fl::repeat_timeout() could not be guaranteed.

Side note: Fl::repeat_timeout() can only work as designed if the timeout code itself runs shorter than the intended timer frequency allows, i.e. if you want 50 repetitions per second, then the timeout handling MUST at least be shorter than 1/50 sec and should also leave room for other event handling. That should be obvious, but just to clarify. Otherwise the behavior is undefined, because FLTK would be 100% busy with servicing one timeout. In such a case, using Fl::add_timeout() with a short delay at the end of the timeout handling code would be more appropriate than to try to force *precise* handling by calling Fl::repeat_timeout(). But this depends on your code.

Whatever the answer is, I would add it to the docs.

Good point, I'll check this and let you know and update the docs.

Thanks in advance, FLTK gurus. 

Welcome.