Re: I lose in threads + GTK+, looking for help

[Reed Hedges <reed mobilerobots com>]

Tomasz Jankowski wrote:
> Welcome!
>
> So far I wrote a few small applications, which were a multithread programs
> based on GTK+. However now I'm working on something "bigger" and after 10
> days of fighting with code and stupidity of win32 platform I fell now like
> total noob... :|
>
> What I should do, if I want execute function, which call some gtk_*
> functions form GTK+ callback function? How I should use gtk_threads_enter ()
> and gdk_threads_leave ()? Should it look like this, or not:
>
> void some_function (void) {
> gdk_threads_enter ();
> /* Some gtk_* functions here */
> gdk_threads_leave ();
> }
>
> void example_gtk_callback_function (void) {
> gdk_threads_leave ();
> some_function ();
> gdk_threads_enter ();
> }

The second funtion is probably not a great way to go, you might end up with 
unwanted race conditions in between gdk_threads_leave() and the beginning of 
some_function when it calls _enter() (depending on what your other threads do).

I use gtk_main_iteration() in a loop, and lock during that function, so no code 
called from any GTK callback ever locks.  But other threads lock (_enter is a 
lock and _leave is an unlock, basically), and other functions called in the loop 
besides gtk_main_iteration() also lock.

There are ways to avoid needing multiple threads as well; One technique that 
works is to encapsulate "requests" or "commands" or "events" in objects 
(structs) and have your other threads queue them up for the main thread to 
process for instance (in fact this is what Win32 does behind the scenes I 
think).  Threading with GTK and GLib is hard. The main problem I've run into is 
GLib's memory allocation pool, which may be accessed at any time.  So you have 
to be prepared for really understanding your whole program and how it accesses 
GTK, GDK and GLib.

Reed