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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
