Re: deadlock



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




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]