On Fri, 1 Jun 2012 22:00:35 +0100 jcup...@gmail.com wrote: > On 1 June 2012 20:41, Chris Vine <ch...@cvine.freeserve.co.uk> wrote: > > jcup...@gmail.com wrote: > >> That's out of date. g_idle_add() does not need any locking by you. > > > > I think you may be confusing this with the fact that with glib >= > > 2.32 it is no longer necessary to call g_thread_init() to make glib > > thread safe, which is of course a completely different issue. > > > > There is a proposal to deprecate the use of the GDK global lock, > > but in a program which does use it, g_idle_add() does not exempt > > you from the need to invoke the global lock in idle callbacks, > > either by doing it in the idle callback yourself or by calling > > gdk_threads_add_idle(). > > I think we must be talking at cross-purposes. g_thread_init() is > becoming optional (it will always be called for you), but you've never > needed to lock either around calls to g_idle_add() and friends, or in > the handler when it is invoked, since it is run by the main loop. > > For example, I posted some sample code ages ago (scroll down a bit): > > http://old.nabble.com/g_main_loop-and-g_async_queue-td21288177.html > > Or have I missed something horribly?
I am not sure if you have missed anything, but you said that the documentation on gdk_threads_add_idle() is "out of date". It isn't (to the best of my knowledge), nor has the position with respect to g_idle_add() changed. Perhaps you were intending to say that if you don't you use the GDK global lock and allow worker threads to address GTK+ via g_idle_add(), but don't need to lock the GDK global lock. Whilst true, that has always been the case. Chris _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
