- * There are primitives for thread-private data - data that every thread
- * has a private instance of (#GPrivate, #GStaticPrivate). There are
- * facilities for one-time initialization (#GOnce, g_once_init_enter()).
- * Finally there are primitives to create and manage threads (#GThread).
- *
- * The threading system is initialized with g_thread_init().
- * You may call any other glib functions in the main thread before
- * g_thread_init() as long as g_thread_init() is not called from
- * a GLib callback, or with any locks held. However, many libraries
- * above GLib does not support late initialization of threads, so
- * doing this should be avoided if possible.
- *
- * Please note that since version 2.24 the GObject initialization
- * function g_type_init() initializes threads. Since 2.32, creating
- * a mainloop will do so too. As a consequence, most applications,
- * including those using GTK+ will run with threads enabled.
- *
- * After calling g_thread_init(), GLib is completely thread safe
- * (all global data is automatically locked), but individual data
- * structure instances are not automatically locked for performance
- * reasons. So, for example you must coordinate accesses to the same
- * #GHashTable from multiple threads. The two notable exceptions from
- * this rule are #GMainLoop and #GAsyncQueue, which <emphasis>are</emphasis>
- * threadsafe and need no further application-level locking to be
- * accessed from multiple threads.
- */
-
-/**
- * G_THREADS_IMPL_POSIX:
- *
- * This macro is defined if POSIX style threads are used.
- */
-
-/**
- * G_THREADS_IMPL_WIN32:
- *
- * This macro is defined if Windows style threads are used.
+ * There are primitives for thread-private data - data that every
+ * thread has a private instance of (#GPrivate). There are facilities
+ * for one-time initialization (#GOnce, g_once_init_enter()). Finally,
+ * there are primitives to create and manage threads (#GThread).
+ *
+ * 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.
+ *
+ * Note that it is not safe to assume that your program has no threads
+ * even if you don't call g_thread_new() yourself. GLib and GIO can
+ * and will create threads for their own purposes in some cases, such
+ * as when using g_unix_signal_source_new() or when using GDBus.
+ *
+ * Originally, UNIX did not have threads, and therefore some traditional
+ * UNIX APIs are problematic in threaded programs. Some notable examples
+ * are
+ *
+ * - C library functions that return data in statically allocated
+ * buffers, such as strtok() or strerror(). For many of these,
+ * there are thread-safe variants with a _r suffix, or you can
+ * look at corresponding GLib APIs (like g_strsplit() or g_strerror()).
+ *
+ * - The functions setenv() and unsetenv() manipulate the process
+ * environment in a not thread-safe way, and may interfere with getenv()
+ * calls in other threads. Note that getenv() calls may be hidden behind
+ * other APIs. For example, GNU gettext() calls getenv() under the
+ * covers. In general, it is best to treat the environment as readonly.
+ * If you absolutely have to modify the environment, do it early in
+ * main(), when no other threads are around yet.
+ *
+ * - The setlocale() function changes the locale for the entire process,
+ * affecting all threads. Temporary changes to the locale are often made
+ * to change the behavior of string scanning or formatting functions
+ * like scanf() or printf(). GLib offers a number of string APIs
+ * (like g_ascii_formatd() or g_ascii_strtod()) that can often be
+ * used as an alternative. Or you can use the uselocale() function
+ * to change the locale only for the current thread.
+ *
+ * - The fork() function only takes the calling thread into the child's
+ * copy of the process image. If other threads were executing in critical
+ * sections they could have left mutexes locked which could easily
+ * cause deadlocks in the new child. For this reason, you should
+ * call exit() or exec() as soon as possible in the child and only
+ * make signal-safe library calls before that.
+ *
+ * - The daemon() function uses fork() in a way contrary to what is
+ * described above. It should not be used with GLib programs.
+ *
+ * GLib itself is internally completely thread-safe (all global data is
+ * automatically locked), but individual data structure instances are
+ * not automatically locked for performance reasons. For example,
+ * you must coordinate accesses to the same #GHashTable from multiple
+ * threads. The two notable exceptions from this rule are #GMainLoop
+ * and #GAsyncQueue, which are thread-safe and need no further
+ * application-level locking to be accessed from multiple threads.
+ * Most refcounting functions such as g_object_ref() are also thread-safe.