In article <5405-fltk.bugs-+FT6Wyec2gCDR8wcTNDzOQ@public.gmane.org>,
 Michael Sweet <mike-B9D8k9nSxTHQT0dZR+AlfA@public.gmane.org> wrote:

> Yes, we can revisit this for FLTK 2, at least from the standpoint of
> changing the awake() function to return a boolean, and perhaps for
> extending this to a true RPC (rather than IPC) mechanism.  However,
> like I've said before I'm not keen on adding a complex, guaranteed
> delivery system unless you can show it can be generally useful to
> a broad range of multi-threaded apps.

I don't want anything complex either. In fact, I would prefer either to: 

- change awake() to not accept any message at all and remove 
thread_message/set_awake_cb() so that awake() is just a way to awake the 
main thread;
- change the current semantics in a way that allows the system queue to 
be guaranteed

(if we have a system queue, let's take the best out of it or not expose 
it at all).

On top of that, support a minimalist RPC, so that Fl::lock/unlock become 
totally unnecessary (less functions exposed, less internal complexity, 
less side cases for the application).