Re: GIO will link with -pthread soon

[Alexander Larsson <alexl redhat com>]

On Fri, 2009-11-20 at 15:27 +0000, Michael Meeks wrote:
> On Fri, 2009-11-20 at 14:02 +0100, Alexander Larsson wrote:
> > > it was fixed a very long time ago. The problem, as you note, is with
> > > everything above libglib in the stack, not with libglib itself.
> >
> > We really need to get our story together here. Either we do our very
> > best to handle late g_thread_init(), or we should fail spectactularly.
> > Silently breaking in minor ways is not a good idea...
> 
> 	Sure; from a performance perspective ORBit2 (and thus GConf) has done a
> g_thread_init(NULL); if !g_threads_supported() for years and years now -
> so linking pthread and doing this sort of thing is unlikely to have any
> performance impact that anyone will notice on any GNOME app.
> 
> 	It does seem though, that the thread has rather strayed from the
> problem of the moment: linking -lpthread (to please gdb's random whim) -
> to whether we should call pthread_init() - which is rather a different
> topic (surely) ?

It is. Consider this thread hijacked. The original problem is fixed:
http://git.gnome.org/cgit/glib/commit/?id=5d97ea298672880ee80964c07b9cf31d604c3df9

However, this old issue reared its ugly head again, with the gio not
being late-thread-initiable. And it would be nice to finally nail it
down.

> 	I'm personally all for always initializing threading - but it would
> also seem to be altogether better if no explicit initialization was
> required too ;-)

At this point I agree with you. glib should imho always initialize
threads. This just makes things more robust in general and fixes
longstanding issues. It is a potential minor (especially considering we
now almost always link to libpthreads) performance loss, but since
threads are more important today (with gio local async i/o using them
and with multi-core cpus being common) this is rarely a problem anyway.

What about making g_slice able to handle late initialization of threads,
but everything else that uses g_thread apis to protect something would
just get threads auto-initialized. Then super-simple apps using just
glist and ghashtable would not get threads initialized, but things like
mainloops and whatnot would always get it.