Re: [gtk-list] multithreaded apps

[Paul Barton-Davis <pbd op net>]

In message <XFMail.990416105106.nathan@islanddata.com>you write:
>What's the best way to handle multithreaded GTK applications?  Should the
>non-main threads just be generating events for the main thread to handle
>graphically?  

This is certainly what I'm doing (my application has 5 threads). I use
a pipe to send a 1 byte "signal" to the GTK/UI thread (why, oh why
doesn't POSIX let us select() on a semaphore!). On receipt, (c/o
gtk_input_add()), the GTK/UI thread goes and checks a (locked) request
queue for things that other threads want doing.

Currently, I get away with just 2 requests: ErrorMessage and TouchDisplay.
The first one formats an error message and stuffs it into a TextViewer
(unless its a fatal error), the second one calls includes a pointer to
an object and a pointer to a function, and calls the function on the object.

(well, thats what it would do if it were in C, but since this is C++,
its not quite like that :)

This second one lets me have lots of objects that come with two
"halves" - one half consisting of a bunch of stuff that can be called
by non-GTK/UI threads, and the other half, mostly connected with
drawing, that can only be called by the GTK/UI thread. The functions
in the non-GTK/UI side call "ui->request (UI::Request *)" to pass
along the request.

Its working pretty well for me so far.

--p