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.