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

> > - 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;
> 
> What use is that?  The current API already provide this sort of
> functionality *as well as* simple message passing.

Simple messaging, with "not guaranteed" written all over it. You can't 
event count on one message being dispatched (as unlikely as you think it 
may be). At least you would free yourself from the messaging semantics 
and ABI complications.

> > - change the current semantics in a way that allows the system queue to 
> > be guaranteed
> 
> You'll have a hard time of doing this without getting deadlocked at
> some point...

I know, that's why I would tend to remove the message passing api using 
the system's queue completely. I wrote that for completeness, if someone 
would ever pop in with a better suggestion to leverage it. I see a dead 
end on WIN32, but I'm not a WIN32 expert.

> I don't see how you can avoid Fl::lock/unlock without mutexes on
> everything.  At some level, we need to limit access to widgets and
> other stuff in FLTK to a single thread, or have suitable interfaces
> that are atomic (and/or protected by mutexes) that can be called by
> multiple threads.  That can get really tricky, as anyone who has
> worked on operating systems, databases, or real-time software can
> tell you.

Yes of course, an eventual RPC api should be thread safe with semantics 
to be defined (user-defined size, automatically grown array, or anything 
that would result in easy immediate usage as long it's reliable and in 
user-space). Should we expose the lock/unlock functions and let threads 
use them before using the RPC api or should the RPC api be atomic by 
itself (using an internal mutex local)? Not exposing the implicit mutex 
would make more evident that those are the only functions allowed in 
threads. I like both types depending on the context. As you say, this 
implies the application should only use that said RPC, or implement it's 
own.

Polling can be implemented via a non messagging awake(), thus there's no 
real refactoring needed here.

> however not all code can be easily refactored this way - try doing
> multiple operations atomically via RPC...

Either call an handler that combines those operations in one, or allow 
multiple RPC calls to be grouped (either by using lock/unlock or an 
atomic vector call that either queues them all or rejects), and 
guarantee that all operations are executed in FIFO order, together, 
after the event loop.

> Also, how do you plan on calling class methods?

Ha, the infamous question :). I would mimic the standard callback 
behavior of FLTK2 widgets (if that's different from 1.1).