Re: Proposal: Enable threads by default



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)

> 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: I'm only using a few
> bits of GLib: GList and GHashtable, and they call into GSlice that is
> not-threadsafe until g_thread_init is called. (I'm currently using
> GThread a bit, but I can replace that with pthread and use the Win32
> pthread implementation for Windows.

If you want to call into glib from multiple threads, then someone has to
call g_thread_init() (and glib and the main program have to be using the
same thread library obviously). Don't worry about implementation details
like GSlice, because those details might change in the future. The only
thing you need to worry about is, if you're calling glib from multiple
threads, you need to call g_thread_init().

-- Dan


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]