Re: g_main_loop() seems stuck

[Paul Davis <pbd Op Net>]

>The above works 100% of the time when it is only one critical response
>dialog that is handled. If after I return to the engine code in the
>above scenario it is followed in rapid succession with another UI
>callback I go through all the motions and end up blocking in the
>g_cond_wait() and no window shows up. This happens 80% of the time.

this is the archetype of a race condition. i would expect that
somewhere, you are not using the locks correctly (i.e. not taking them
at the right points and releasing them at the right points). issues
with condition variables are common sources of simple race conditions
because (for some strange reason) they are not well understood.

you will probably not be able to track such bugs in gdb, because gdb's
control over the app changes its execution timing, and thus changes
the probabilities of encountering the bug. thats also probably why it
works over telnet/ssh - execution speed of each thread is changed by
the network latency.

most of the people i know who do multithreaded programming with GTK
(myself included) do not bother with gdk_thread_{enter,leave}, but
instead have a single thread making GTK/GDK calls. all other
threads writing requests to a pipe that is monitored by the main glib
event loop from the main gui thread. this removes the need to use the
gdk thread lock (you don't even need g_thread_init()), and makes sure
that this type of condition does not come from the GUI code.

--p