Re: Proposal: Enable threads by default

[Stefan Kost <ensonic hora-obscura de>]

Am 06.12.2009 21:22, schrieb Dan Winship:
> On 12/06/2009 10:05 AM, Adam Goode wrote:
>> I guess what I really would like is a way that I can use GLib privately
>> from my library and have it be thread-safe without requiring users of my
>> library have to link against gthread and call g_thread_init. I think it
>> is primarily just GSlice that is the trouble here
> 
> Currently, everything in libglib (including GSlice) can deal with you
> calling g_thread_init() at any time, although the documentation pretty
> much explicitly claims otherwise. Maybe we should change the rules
> around g_thread_init as part of this:
> 
>     1) If you want to call g_mem_set_vtable(), it must be the very first
>        glib call in the program. (This rule already exists, although
>        the current g_thread_init() docs contradict it.)
> 
>     2) If you want to call g_thread_init() *with a non-NULL parameter*,
>        you have to call it before any other glib method except
>        g_mem_set_vtable(). (This is the current g_thread_init rule,
>        weakened to only apply to the uncommon case.)
> 
>     3) You can call g_thread_init(NULL) at any time, and everything in
>        libglib will deal with it. (Already true, but undocumented.)
>        Libraries at higher levels of the stack might not work correctly
>        though if you call g_thread_init() after calling into that
>        library. (Already true and documented.)
> 
>     4) Calling g_thread_init(NULL) after g_thread_init() has already
>        been called once (with a NULL or non-NULL param) is a no-op.
>        (We don't actually want this rule, but it avoids problems with
>        apps that were mistakenly calling g_thread_init() after
>        g_type_init() before.)
> 
>     5) g_type_init() calls g_thread_init(NULL)


Wouldn't it make sense to file a bug then? Attach a patch that fixes the docs,
get it reviewed and push upon agreement. This is a crucial detail and getting
those things wrong makes libraries unstable or crashy, which might reflect bad
on glib even.

Thanks,
Stefan