Re: Making GLib thread-safe

[Jeff Garzik <jgarzik pobox com>]

Owen Taylor wrote:
> Jeff Garzik <jgarzik@pobox.com> writes:
> > I keep running into GLib thread safety issues coding my current
> > GNOME app.

> > Has anyone put any work towards making GLib thread-safe?  I'd like
> > to start a new CVS branch and push forward towards this goal, unless
> > anyone has objections.

> > It seems to me like I should only have to define mutexes for each
> > static variable.  And if _REENTRANT is not defined, the mutex locks
> > evaluate to null calls.

> > (I'm searching the gtk-list archives now for glib+thread references)

> Such questions (and anything about future work planned for
> GTK+) should probably be directed to gtk-devel-list@redhat.com.
> There has been some discussion there recently about adding
> threading primitives to GLIB, but nothing that I remember
> about adding reentrancy to GLIB itself.

> (Having reentrancy in GLIB is a little less urgent, since GTK+
> is only going to be explicit-locking thread-safe in the
> near future, but glib is a pretty useful library, so I
> suppose it would be nice to be able to use it in threaded
> code without grabbing the global GTK+ lock. 

> Some care would have to be done to make sure that this didn't kill
> performance - perhaps some resources like the GList free
> lists should be per-thread)

Take a look at GLIB_1_1_4_THREADS, particularly glibconfig.h output,
garray.c and gcache.c.  Granted those are simpler examples of
thread-safe conversion, but let me know if something looks funky or
just totally wrong.  :)

	Jeff