2010/8/4 Tomas Soltys <tomas.sol...@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 >> tadeb...@gmail.com >> tadej.borov...@gmail.com >> > > > _______________________________________________ > gtk-app-devel-list mailing list > gtk-app-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list > _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
