Re: GTK deadlock in gtk_main

[KC <kcc1967 gmail com>]

2010/8/4 Tomas Soltys <tomas soltys range-software com>:
> Hi,
>
> So what you suggest is to have gdk_threads_enter and gdk_threads_leave at
> the beginning and at the end of the idle function?
>
> Is this really intended?
YES,
check http://library.gnome.org/devel/gdk/unstable/gdk3-Threads.html

Idles, timeouts, and input functions from GLib, such as g_idle_add(),
are executed outside of the main GTK+ lock. So, if you need to call
GTK+ inside of such a callback, you must surround the callback with a
gdk_threads_enter()/gdk_threads_leave() pair or use
gdk_threads_add_idle_full() which does this for you. However, event
dispatching from the mainloop is still executed within the main GTK+
lock, so callback functions connected to event signals like
GtkWidget::button-press-event, do not need thread protection.

Regards
KC


> Anyway, thanks for your help.
>
> Regards,
> Tomas
>
> > Hi.
> >
> > You're having troubles because gtk_main_iteration_do() does it's own
> > unlock/lock cycle.
> >
> > When your idle callback is executed, your mutex is unlocked.
> > gtk_main_iteration_do() "unlocks" it again, executes whatever is there
> > to be executed and locks it. Now control returns back to main loop,
> > which tries to lock mutex and here you have your lock.
> >
> > Tadej
> >
> > --
> > Tadej BorovÃÂak
> > tadeboro.blogspot.com
> > tadeboro gmail com
> > tadej borovsak gmail com
>
>
> _______________________________________________
> gtk-app-devel-list mailing list
> gtk-app-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list