Re: Help with a multi-threaded application. Spot a crash.

[Chris Vine <chris cvine freeserve co uk>]

On Fri, 1 Jun 2012 22:00:35 +0100
jcupitt gmail com wrote:
> On 1 June 2012 20:41, Chris Vine <chris cvine freeserve co uk> wrote:
> > jcupitt 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