Yuri D'Elia wrote:

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;

What use is that?  The current API already provide this sort of
functionality *as well as* simple message passing.

- 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...

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

No queue is infinite in size/length.

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).

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.

Implementing an RPC system so that all FLTK calls are directed from
the main thread is one way to avoid explicit Fl::lock/unlock calls,
however not all code can be easily refactored this way - try doing
multiple operations atomically via RPC...  Also, how do you plan on
calling class methods?

--
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Document Software          http://www.easysw.com