GNOME Bugzilla – Bug 660744
finish killing g_thread_init()
Last modified: 2011-10-05 09:31:30 UTC
All of the synchronisation primatives (mutex, cond, recmutex, rwlock, private) are completely free of the need for g_thread_init(), and g_thread_new() works without it too. There are just a couple of places left inside GLib that have thread-unsafe initialisation that g_thread_init() forces to occur in single-threaded context. We need to finish up the ctor story to make this work.
Created attachment 198173 [details] [review] Clean up process of calling g_debug_init() Make sure that it calls absolutely nothing that may ever recurse back into GLib again: - g_ascii_strcasecmp() is unsafe because it has g_return_if_fail() at the top. As far as I know, the only ASCII character letter that would get special treatment here is "i" and that appears in neither "help" nor "all". - g_getenv() is very complicated on Windows, so use a simple version that is sufficient for our purposes. Now that it's completely safe, we can just call it from g_logv() in the usual way without all of the hacks.
Created attachment 198174 [details] [review] Deprecate g_thread_init() Move the last few things that needed thread-safe initialisation to a global ctor.
Review of attachment 198173 [details] [review]: Looks good to me.
Review of attachment 198174 [details] [review]: Forgot git add glib-init.[hc] ?
Review of attachment 198174 [details] [review]: Also, we need to add a paragraph about non-threadsafe setup code to the thread docs. Where we explain that it is safe to call things like setenv(), etc before creating the first thread. We should also say somewhere that it is no longer necessary to link against gthread, and review the docs for mentions of it. ::: glib/deprecated/gthread-deprecated.c @@ +139,3 @@ + * other thread-related functions of GLib. Those can be used without + * having to link with the thread libraries.</para></note> + */ Needs a Deprecated:2.32: It is no longer necessary to explicitly initialize the thread system before using any thread-related functions. @@ +148,3 @@ + * Returns: %TRUE if threads have been initialized. + * + * Since: 2.20 Needs a Deprecated:2.32: Threads are always initialized.
Created attachment 198223 [details] [review] Deprecate g_thread_init() Move the last few things that needed thread-safe initialisation to a global ctor.
Review of attachment 198223 [details] [review]: ::: glib/deprecated/gthread-deprecated.c @@ +139,3 @@ + * other thread-related functions of GLib. Those can be used without + * having to link with the thread libraries.</para></note> + */ This is where a dummy g_thread_init() should go. (And a dummy g_thread_init_glib()). ::: glib/glib-init.c @@ +243,3 @@ + +#else +# error Your platform/compiler is missing constructor support This would be a regression on those platforms. I'd prefer we not commit this patch until we have some plan for fallbacks in place. Probably these compilers as a starting list: * LLVM * Sun CC * MSVC One approach is to just keep the internal calls to g_thread_init(), and make it a no-op on GCC. The downside is this is extremely likely to bitrot over time. We could go with the C++ fallback and get good coverage I think. ::: glib/glib.symbols @@ -1096,3 +1096,2 @@ g_thread_exit g_thread_functions_for_glib_use -g_thread_init_glib I'd prefer not to remove any symbols. Yes, no one should be calling it, but it's still something that can be flagged as an ABI change.
Review of attachment 198223 [details] [review]: ::: glib/deprecated/gthread-deprecated.c @@ +139,3 @@ + * other thread-related functions of GLib. Those can be used without + * having to link with the thread libraries.</para></note> + */ This is a little bit complicated. The dummy g_thread_init() needs to be in libgthread. That's a consequence of the fact that some people might have done direct linking (and therefore expect to find that symbol in exactly that library). At the same time, we might want to have it in libglib as well so that we can modify the gthread pkgconfig file to no longer link to libgthread without breaking people who still call g_thread_init(). On the other hand, maybe we could just leave the pkg-config alone and advise people to stop using it. Another option (one that I don't particular care for) would be to symlink libgthread to libglib. Apparently that works, and would solve both issues. ::: glib/glib-init.c @@ +243,3 @@ + +#else +# error Your platform/compiler is missing constructor support MSVC is handled by the G_OS_WIN32 case. I think clang supports the GCC attributes (and even defines __GNUC__ based on some bug reports we've seen). Alex is best equipped to comment on this. ::: glib/glib.symbols @@ -1096,3 +1096,2 @@ g_thread_exit g_thread_functions_for_glib_use -g_thread_init_glib I had a feeling you'd have a problem with this :) I'll add it back in as a do-nothing.
Comment on attachment 198223 [details] [review] Deprecate g_thread_init() Committed with g_thread_init_glib() added back in.
Review of attachment 198223 [details] [review]: ::: glib/glib-init.c @@ +243,3 @@ + +#else +# error Your platform/compiler is missing constructor support This should work fine for win32 and gcc, and llvm. We should make sure to add support for sun cc though. Should be easy as this is open-coded rather than a generally usable macro.