Re: When to call g_thread_init(), again...

[Tim Janik <timj imendio com>]

On Fri, 15 Aug 2008, Christian Dywan wrote:

> I think both is rather open for missunderstandings actually, before and
> after the improvement of the g_thread_init documentation.
> g_mem_set_vtable clearly asserts that it must be called *before
> anything else* and so does g_thread_init.
>
> There is no ambiguity with regard to when g_thread_init should be
> called as I see it. At best it's paradox that one is supposed to call
> two functions before each other, ie. before any Glib function.

There's no *practical* ambiguity. If you really want to change the
memory allocators, g_mem_set_vtable() needs to be called before
*any* other glib function (because all glib functions can potentially
allocate memory), including g_thread_init().

g_thread_init() really *should* be called before all other glib functions
(except g_mem_set_vtable() which sets up the allocator vtable that's needed
by everything in glib, including g_thread_init), but in practice we've been
trying to make late g_thread_init() calls work nevertheless (Owen's decision
AFAIK, because not doing so will potentially break a bunch of libraries
on Unix/windows).

About not calling g_thread_init() and using glib from different threads,
or even using glib from threads that have been created by non-glib functions
(like pthread_create), I'd say this is generally a _very_ bad idea.
I'm not entirely sure wether it'll break GLib currently, but it may
very well break badly in the future, if we ever want to make use of
fast thread local storage:
	http://people.redhat.com/drepper/tls.pdf

> ciao,
>    Christian

---
ciaoTJ