Re: deadlock

[Owen Taylor <otaylor redhat com>]

On Thu, 2005-03-10 at 21:18 +0100, Dirk Huenniger wrote:
> Hello everybody,
> My name is Dirk, I'm writing a control programm for a 1m telescope in
> Germany. The current status of the device is periodically displayed in GTK 
> using a thread. When the user clicks the quit butten a callback routine is
> started. At the same time  my thread does a gtk_threads_enter(). But it 
> cannot enter because the callback is running so it waits inside the gtk_threads_enter
> routine. My callback routine askes the thread to quit and waits for that
> to happen. But the thread cannot react because it is waiting inside 
> gtk_threads_enter(). So everything is hanging now. I also
> tried to quit my thread in a routine added with gtk_quit_add, it did not
> help. But the following evil hack worked:
>
> /* my callback routine*/
> menu_exit                              (GtkMenuItem     *menuitem,
>                                          gpointer         user_data)
> {
>    gdk_threads_leave(); /* give back gdk "semaphore" ?????*/
>    thread_stop();       /* let thread take it  and give it back*/
>    gdk_threads_enter(); /* take it again*/
> }

There's nothing yucky about this at all. GTK+ is reentrant
at this point, so it's fine to release the lock temporarily. If you
called, say, gtk_dialog_run() at this point, the same thing would
happen.

Regards,
                                                Owen

(The general question of when it's OK to release the GTK+ lock isn't
something I can give a really well defined answer to. If the other
thread isn't going to modify the widget hierarchy, then it's fine
to release it in almost any callback.

If the other thread *is* modifying the same widget hierarchy, then
it's fine to release it in callbacks like ::clicked, ::activate, 
etc, but I wouldn't do it in ::<blah>-event callbacks, ::size-allocate,
::size-request, since those involve walking over the widget hierarchy.)