Re: Is GIOChannel thread-safe?

[rsteinke w-link net]

> From: Jonas Borgstr?m <jonas codefactory se>
>
> Hi,
>
> I'm having some problems using the glib event loop and iochannels
> in a multi-threaded application. The documentation states:
>
> "To allow multiple independent sets of sources to be handled in
>  different threads, each source is associated with a GMainContext. 
>  A GMainContext can only be running in a single thread, but sources can
>  be added to it and removed from it from other threads."
>
> The application segfaults or hangs after running for a while on SMP
> machines.
> I've managed to reproduce this on both linux 2.2 (2 cpu:s) and solaris
> (4 cpu:s)
>
> A simple test-case that triggers this issue on SMP machines can be found
> here. Or is this test-case doing something "illegal"?
>
> http://afs.codefactory.se/~jonas/roadrunner/gsource-test.c
>
> This test-case segfaults after a few seconds on the solaris box and
> within
> a minute on the linux machine. I haven't been able to reproduce this on
> single cpu machines.
>
> I'm not sure what causes this, but it looks like it can have something
> to do with that g_io_channel_ref/unref aren't thread-safe.
>
> http://afs.codefactory.se/~jonas/roadrunner/giochannel.c-workaround.diff
>
> This patch adds a static mutex around the ref and unref functions and
> that seems to fix this issue, but it is probably not the correct/best 
> solution.
>
> So, what do you think, is this a bug or is gsource-test.c doing
> something
> "illegal"?
>
> (I'm using glib-2.2.1)

I believe the canonical answer for this is that most Glib structures
don't do their own locking, so if you access them in multiple threads
you need to add your own mutex. Calling ref/unref functions is certainly
accessing the structures.

Ron Steinke

"The sound of gunfire, off in the distance. I'm getting used to it now."
-- Talking Heads