GLib is quickly moving towards initializing threads automatically at
program startup. This is already the case for Gtk+ programs with GLib 2.24:
http://developer.gnome.org/glib/2.28/glib-Threads.html
"Please note that since version 2.24 the GObject initialization function
g_type_init() initializes threads (with a NULL argument), so most
applications, including those using Gtk+ will run with threads enabled.
If you want a special thread implementation, make sure you call
g_thread_init() before g_type_init() is called."
...and it will be the case everywhere with GLib 2.32:
http://git.gnome.org/browse/glib/tree/glib/gthread.c?h=master
* The GLib threading system used to be initialized with g_thread_init().
* This is no longer necessary. Since version 2.32, the GLib threading
* system is automatically initialized at the start of your program,
* and all thread-creation functions and synchronization primitives
* are available right away.
Is there any reason we shouldn't remove the thread options from
configure.in and CMakeOptions.txt along with USE_THREADS and hard-code
thread support?
