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.)
_______________________________________________
gtk-app-devel-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
