X-Git-Url: http://review.tizen.org/git/?a=blobdiff_plain;ds=sidebyside;f=glib%2Fgthread.c;h=ea8e5f9656f55945bb365f645e25dee26b61ed6b;hb=7e3d32b7053b47ca7feecf185abac96b619770c2;hp=ffac638a15fc0aab2dbce68cddcc04b6eb2a865c;hpb=4d12e0d66f1641a6eb2ba9c65579935136f6ef46;p=platform%2Fupstream%2Fglib.git
diff --git a/glib/gthread.c b/glib/gthread.c
index ffac638..ea8e5f9 100644
--- a/glib/gthread.c
+++ b/glib/gthread.c
@@ -100,44 +100,37 @@
* 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()).
- *
- *
- * 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.
- *
- *
- * setlocale() 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.
- *
- *
- * fork() 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.
- *
- *
- * daemon() uses fork() in a way contrary to what is described
- * above. It should not be used with GLib programs.
- *
- *
+ *
+ * - 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
@@ -155,19 +148,17 @@
* G_LOCK_DEFINE:
* @name: the name of the lock
*
- * The G_LOCK_* macros provide a convenient interface to #GMutex.
+ * The #G_LOCK_ macros provide a convenient interface to #GMutex.
* #G_LOCK_DEFINE defines a lock. It can appear in any place where
* variable definitions may appear in programs, i.e. in the first block
* of a function or outside of functions. The @name parameter will be
* mangled to get the name of the #GMutex. This means that you
* can use names of existing variables as the parameter - e.g. the name
* of the variable you intend to protect with the lock. Look at our
- * give_me_next_number() example using the
- * G_LOCK_* macros:
+ * give_me_next_number() example using the #G_LOCK macros:
*
- *
- * Using the G_LOCK_* convenience macros
- *
+ * Here is an example for using the #G_LOCK convenience macros:
+ * |[
* G_LOCK_DEFINE (current_number);
*
* int
@@ -182,8 +173,7 @@
*
* return ret_val;
* }
- *
- *
+ * ]|
*/
/**
@@ -234,33 +224,26 @@
*
* The #GMutex struct is an opaque data structure to represent a mutex
* (mutual exclusion). It can be used to protect data against shared
- * access. Take for example the following function:
+ * access.
*
- *
- * A function which will not work in a threaded environment
- *
+ * Take for example the following function:
+ * |[
* int
* give_me_next_number (void)
* {
* static int current_number = 0;
*
- * /* now do a very complicated calculation to calculate the new
- * * number, this might for example be a random number generator
- * */
+ * // now do a very complicated calculation to calculate the new
+ * // number, this might for example be a random number generator
* current_number = calc_next_number (current_number);
*
* return current_number;
* }
- *
- *
- *
+ * ]|
* It is easy to see that this won't work in a multi-threaded
* application. There current_number must be protected against shared
* access. A #GMutex can be used as a solution to this problem:
- *
- *
- * Using GMutex to protected a shared variable
- *
+ * |[
* int
* give_me_next_number (void)
* {
@@ -268,15 +251,13 @@
* static int current_number = 0;
* int ret_val;
*
- * g_mutex_lock (&mutex);
+ * g_mutex_lock (&mutex);
* ret_val = current_number = calc_next_number (current_number);
- * g_mutex_unlock (&mutex);
+ * g_mutex_unlock (&mutex);
*
* return ret_val;
* }
- *
- *
- *
+ * ]|
* Notice that the #GMutex is not initialised to any particular value.
* Its placement in static storage ensures that it will be initialised
* to all-zeros, which is appropriate.
@@ -284,8 +265,7 @@
* If a #GMutex is placed in other contexts (eg: embedded in a struct)
* then it must be explicitly initialised using g_mutex_init().
*
- * A #GMutex should only be accessed via g_mutex_
- * functions.
+ * A #GMutex should only be accessed via g_mutex_ functions.
*/
/* GRecMutex Documentation {{{1 -------------------------------------- */
@@ -304,7 +284,7 @@
* g_rec_mutex_init() on it and g_rec_mutex_clear() when done.
*
* A GRecMutex should only be accessed with the
- * g_rec_mutex_ functions.
+ * g_rec_mutex_ functions.
*
* Since: 2.32
*/
@@ -325,9 +305,8 @@
* simultaneous read-only access (by holding the 'reader' lock via
* g_rw_lock_reader_lock()).
*
- *
- * An array with access functions
- *
+ * Here is an example for an array with access functions:
+ * |[
* GRWLock lock;
* GPtrArray *array;
*
@@ -339,10 +318,10 @@
* if (!array)
* return NULL;
*
- * g_rw_lock_reader_lock (&lock);
- * if (index < array->len)
+ * g_rw_lock_reader_lock (&lock);
+ * if (index < array->len)
* retval = g_ptr_array_index (array, index);
- * g_rw_lock_reader_unlock (&lock);
+ * g_rw_lock_reader_unlock (&lock);
*
* return retval;
* }
@@ -350,35 +329,30 @@
* void
* my_array_set (guint index, gpointer data)
* {
- * g_rw_lock_writer_lock (&lock);
+ * g_rw_lock_writer_lock (&lock);
*
* if (!array)
- * array = g_ptr_array_new ();
+ * array = g_ptr_array_new ();
*
* if (index >= array->len)
* g_ptr_array_set_size (array, index+1);
* g_ptr_array_index (array, index) = data;
*
- * g_rw_lock_writer_unlock (&lock);
+ * g_rw_lock_writer_unlock (&lock);
* }
- *
- *
- * This example shows an array which can be accessed by many readers
- * (the my_array_get() function) simultaneously,
- * whereas the writers (the my_array_set()
- * function) will only be allowed once at a time and only if no readers
- * currently access the array. This is because of the potentially
- * dangerous resizing of the array. Using these functions is fully
- * multi-thread safe now.
- *
- *
+ * ]|
+ * This example shows an array which can be accessed by many readers
+ * (the my_array_get() function) simultaneously, whereas the writers
+ * (the my_array_set() function) will only be allowed one at a time
+ * and only if no readers currently access the array. This is because
+ * of the potentially dangerous resizing of the array. Using these
+ * functions is fully multi-thread safe now.
*
* If a #GRWLock is allocated in static storage then it can be used
* without initialisation. Otherwise, you should call
* g_rw_lock_init() on it and g_rw_lock_clear() when done.
*
- * A GRWLock should only be accessed with the
- * g_rw_lock_ functions.
+ * A GRWLock should only be accessed with the g_rw_lock_ functions.
*
* Since: 2.32
*/
@@ -399,11 +373,9 @@
* another thread publishes the data, it can signal one of the waiting
* threads to wake up to collect the data.
*
- *
- *
- * Using GCond to block a thread until a condition is satisfied
- *
- *
+ * Here is an example for using GCond to block a thread until a condition
+ * is satisfied:
+ * |[
* gpointer current_data = NULL;
* GMutex data_mutex;
* GCond data_cond;
@@ -431,21 +403,19 @@
*
* return data;
* }
- *
- *
- *
+ * ]|
* Whenever a thread calls pop_data() now, it will wait until
* current_data is non-%NULL, i.e. until some other thread
* has called push_data().
*
* The example shows that use of a condition variable must always be
* paired with a mutex. Without the use of a mutex, there would be a
- * race between the check of current_data by the
- * while loop in pop_data and waiting.
- * Specifically, another thread could set pop_data
- * after the check, and signal the cond (with nobody waiting on it)
- * before the first thread goes to sleep. #GCond is specifically useful
- * for its ability to release the mutex and go to sleep atomically.
+ * race between the check of @current_data by the while loop in
+ * pop_data() and waiting. Specifically, another thread could set
+ * @current_data after the check, and signal the cond (with nobody
+ * waiting on it) before the first thread goes to sleep. #GCond is
+ * specifically useful for its ability to release the mutex and go
+ * to sleep atomically.
*
* It is also important to use the g_cond_wait() and g_cond_wait_until()
* functions only inside a loop which checks for the condition to be
@@ -453,11 +423,10 @@
* not be true even after it returns.
*
* If a #GCond is allocated in static storage then it can be used
- * without initialisation. Otherwise, you should call g_cond_init() on
- * it and g_cond_clear() when done.
+ * without initialisation. Otherwise, you should call g_cond_init()
+ * on it and g_cond_clear() when done.
*
- * A #GCond should only be accessed via the g_cond_
- * functions.
+ * A #GCond should only be accessed via the g_cond_ functions.
*/
/* GThread Documentation {{{1 ---------------------------------------- */
@@ -467,7 +436,7 @@
*
* The #GThread struct represents a running thread. This struct
* is returned by g_thread_new() or g_thread_try_new(). You can
- * obtain the #GThread struct representing the current thead by
+ * obtain the #GThread struct representing the current thread by
* calling g_thread_self().
*
* GThread is refcounted, see g_thread_ref() and g_thread_unref().
@@ -549,7 +518,7 @@ G_LOCK_DEFINE_STATIC (g_thread_new);
*
* A #GOnce must be initialized with this macro before it can be used.
*
- * |[
+ * |[
* GOnce my_once = G_ONCE_INIT;
* ]|
*
@@ -589,7 +558,7 @@ G_LOCK_DEFINE_STATIC (g_thread_new);
* Calling g_once() recursively on the same #GOnce struct in
* @func will lead to a deadlock.
*
- * |[
+ * |[
* gpointer
* get_debug_flags (void)
* {
@@ -644,17 +613,17 @@ g_once_impl (GOnce *once,
* blocked until initialization completed. To be used in constructs
* like this:
*
- * |[
+ * |[
* static gsize initialization_value = 0;
*
- * if (g_once_init_enter (&initialization_value))
+ * if (g_once_init_enter (&initialization_value))
* {
- * gsize setup_value = 42; /** initialization code here **/
+ * gsize setup_value = 42; // initialization code here
*
- * g_once_init_leave (&initialization_value, setup_value);
+ * g_once_init_leave (&initialization_value, setup_value);
* }
*
- * /** use initialization_value here **/
+ * // use initialization_value here
* ]|
*
* Returns: %TRUE if the initialization section should be entered,
@@ -903,11 +872,11 @@ g_thread_new_internal (const gchar *name,
* waiting thread will be woken up and get @retval as the return value
* of g_thread_join().
*
- * Calling g_thread_exit (retval) is equivalent to
+ * Calling g_thread_exit() with a parameter @retval is equivalent to
* returning @retval from the function @func, as given to g_thread_new().
*
* You must only call g_thread_exit() from a thread that you created
- * yourself with g_thread_new() or related APIs. You must not call
+ * yourself with g_thread_new() or related APIs. You must not call
* this function from a thread created with another threading library
* or or from within a #GThreadPool.
*/