Re: GIO will link with -pthread soon

[Michael Meeks <michael meeks novell com>]

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) ?

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

> I guess orbit needing this is the main reason why we can't just make it
> fail?

	Well - hmm; I guess GConf has (had?) this "no init required" philosophy
which can make for a nice API, but means that gconf_orb_get()
initializes the ORB the first time it's called. It is hard to see how
(with a deprecated _init function in the case of gconf) - a library can
be setup to demand initialize things that may need threads.

	Of course - iff we could encourage people to merge the gconf-dbus
branch, then that particular problem might go away.

	HTH,

		Michael.

-- 
 michael meeks novell com  <><, Pseudo Engineer, itinerant idiot