1 /* 2 * This file is part of gtkD. 3 * 4 * gtkD is free software; you can redistribute it and/or modify 5 * it under the terms of the GNU Lesser General Public License 6 * as published by the Free Software Foundation; either version 3 7 * of the License, or (at your option) any later version, with 8 * some exceptions, please read the COPYING file. 9 * 10 * gtkD is distributed in the hope that it will be useful, 11 * but WITHOUT ANY WARRANTY; without even the implied warranty of 12 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the 13 * GNU Lesser General Public License for more details. 14 * 15 * You should have received a copy of the GNU Lesser General Public License 16 * along with gtkD; if not, write to the Free Software 17 * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110, USA 18 */ 19 20 // generated automatically - do not change 21 // find conversion definition on APILookup.txt 22 // implement new conversion functionalities on the wrap.utils pakage 23 24 /* 25 * Conversion parameters: 26 * inFile = 27 * outPack = gthread 28 * outFile = Cond 29 * strct = GCond 30 * realStrct= 31 * ctorStrct= 32 * clss = Cond 33 * interf = 34 * class Code: No 35 * interface Code: No 36 * template for: 37 * extend = 38 * implements: 39 * prefixes: 40 * - g_cond_ 41 * omit structs: 42 * omit prefixes: 43 * omit code: 44 * omit signals: 45 * imports: 46 * - gthread.Mutex 47 * structWrap: 48 * - GMutex* -> Mutex 49 * module aliases: 50 * local aliases: 51 * overrides: 52 */ 53 54 module gthread.Cond; 55 56 public import gtkc.gthreadtypes; 57 58 private import gtkc.gthread; 59 private import glib.ConstructionException; 60 61 private import gthread.Mutex; 62 63 64 65 /** 66 * Threads act almost like processes, but unlike processes all threads 67 * of one process share the same memory. This is good, as it provides 68 * easy communication between the involved threads via this shared 69 * memory, and it is bad, because strange things (so called 70 * "Heisenbugs") might happen if the program is not carefully designed. 71 * In particular, due to the concurrent nature of threads, no 72 * assumptions on the order of execution of code running in different 73 * threads can be made, unless order is explicitly forced by the 74 * programmer through synchronization primitives. 75 * 76 * The aim of the thread-related functions in GLib is to provide a 77 * portable means for writing multi-threaded software. There are 78 * primitives for mutexes to protect the access to portions of memory 79 * (GMutex, GRecMutex and GRWLock). There is a facility to use 80 * individual bits for locks (g_bit_lock()). There are primitives 81 * for condition variables to allow synchronization of threads (GCond). 82 * There are primitives for thread-private data - data that every 83 * thread has a private instance of (GPrivate). There are facilities 84 * for one-time initialization (GOnce, g_once_init_enter()). Finally, 85 * there are primitives to create and manage threads (GThread). 86 * 87 * The GLib threading system used to be initialized with g_thread_init(). 88 * This is no longer necessary. Since version 2.32, the GLib threading 89 * system is automatically initialized at the start of your program, 90 * and all thread-creation functions and synchronization primitives 91 * are available right away. 92 * 93 * Note that it is not safe to assume that your program has no threads 94 * even if you don't call g_thread_new() yourself. GLib and GIO can 95 * and will create threads for their own purposes in some cases, such 96 * as when using g_unix_signal_source_new() or when using GDBus. 97 * 98 * Originally, UNIX did not have threads, and therefore some traditional 99 * UNIX APIs are problematic in threaded programs. Some notable examples 100 * are 101 * 102 * C library functions that return data in statically allocated 103 * buffers, such as strtok() or strerror(). For many of these, 104 * there are thread-safe variants with a _r suffix, or you can 105 * look at corresponding GLib APIs (like g_strsplit() or g_strerror()). 106 * 107 * setenv() and unsetenv() manipulate the process environment in 108 * a not thread-safe way, and may interfere with getenv() calls 109 * in other threads. Note that getenv() calls may be 110 * “hidden” behind other APIs. For example, GNU gettext() 111 * calls getenv() under the covers. In general, it is best to treat 112 * the environment as readonly. If you absolutely have to modify the 113 * environment, do it early in main(), when no other threads are around yet. 114 * 115 * setlocale() changes the locale for the entire process, affecting 116 * all threads. Temporary changes to the locale are often made to 117 * change the behavior of string scanning or formatting functions 118 * like scanf() or printf(). GLib offers a number of string APIs 119 * (like g_ascii_formatd() or g_ascii_strtod()) that can often be 120 * used as an alternative. Or you can use the uselocale() function 121 * to change the locale only for the current thread. 122 * 123 * fork() only takes the calling thread into the child's copy of the 124 * process image. If other threads were executing in critical 125 * sections they could have left mutexes locked which could easily 126 * cause deadlocks in the new child. For this reason, you should 127 * call exit() or exec() as soon as possible in the child and only 128 * make signal-safe library calls before that. 129 * 130 * daemon() uses fork() in a way contrary to what is described 131 * above. It should not be used with GLib programs. 132 * 133 * GLib itself is internally completely thread-safe (all global data is 134 * automatically locked), but individual data structure instances are 135 * not automatically locked for performance reasons. For example, 136 * you must coordinate accesses to the same GHashTable from multiple 137 * threads. The two notable exceptions from this rule are GMainLoop 138 * and GAsyncQueue, which are thread-safe and 139 * need no further application-level locking to be accessed from 140 * multiple threads. Most refcounting functions such as g_object_ref() 141 * are also thread-safe. 142 */ 143 public class Cond 144 { 145 146 /** the main Gtk struct */ 147 protected GCond* gCond; 148 149 150 /** Get the main Gtk struct */ 151 public GCond* getCondStruct() 152 { 153 return gCond; 154 } 155 156 157 /** the main Gtk struct as a void* */ 158 protected void* getStruct() 159 { 160 return cast(void*)gCond; 161 } 162 163 /** 164 * Sets our main struct and passes it to the parent class 165 */ 166 public this (GCond* gCond) 167 { 168 this.gCond = gCond; 169 } 170 171 /** 172 */ 173 174 /** 175 * Initialises a GCond so that it can be used. 176 * This function is useful to initialise a GCond that has been 177 * allocated as part of a larger structure. It is not necessary to 178 * initialise a GCond that has been statically allocated. 179 * To undo the effect of g_cond_init() when a GCond is no longer 180 * needed, use g_cond_clear(). 181 * Calling g_cond_init() on an already-initialised GCond leads 182 * to undefined behaviour. 183 * Since 2.32 184 */ 185 public void init() 186 { 187 // void g_cond_init (GCond *cond); 188 g_cond_init(gCond); 189 } 190 191 /** 192 * Frees the resources allocated to a GCond with g_cond_init(). 193 * This function should not be used with a GCond that has been 194 * statically allocated. 195 * Calling g_cond_clear() for a GCond on which threads are 196 * blocking leads to undefined behaviour. 197 * Since 2.32 198 */ 199 public void clear() 200 { 201 // void g_cond_clear (GCond *cond); 202 g_cond_clear(gCond); 203 } 204 205 /** 206 * Atomically releases mutex and waits until cond is signalled. 207 * When this function returns, mutex is locked again and owned by the 208 * calling thread. 209 * When using condition variables, it is possible that a spurious wakeup 210 * may occur (ie: g_cond_wait() returns even though g_cond_signal() was 211 * not called). It's also possible that a stolen wakeup may occur. 212 * This is when g_cond_signal() is called, but another thread acquires 213 * mutex before this thread and modifies the state of the program in 214 * such a way that when g_cond_wait() is able to return, the expected 215 * condition is no longer met. 216 * For this reason, g_cond_wait() must always be used in a loop. See 217 * the documentation for GCond for a complete example. 218 * Params: 219 * mutex = a GMutex that is currently locked 220 */ 221 public void wait(Mutex mutex) 222 { 223 // void g_cond_wait (GCond *cond, GMutex *mutex); 224 g_cond_wait(gCond, (mutex is null) ? null : mutex.getMutexStruct()); 225 } 226 227 /** 228 * Warning 229 * g_cond_timed_wait has been deprecated since version 2.32 and should not be used in newly-written code. Use g_cond_wait_until() instead. 230 * Waits until this thread is woken up on cond, but not longer than 231 * until the time specified by abs_time. The mutex is unlocked before 232 * falling asleep and locked again before resuming. 233 * If abs_time is NULL, g_cond_timed_wait() acts like g_cond_wait(). 234 * This function can be used even if g_thread_init() has not yet been 235 * called, and, in that case, will immediately return TRUE. 236 * To easily calculate abs_time a combination of g_get_current_time() 237 * and g_time_val_add() can be used. 238 * Params: 239 * mutex = a GMutex that is currently locked 240 * absTime = a GTimeVal, determining the final time 241 * Returns: TRUE if cond was signalled, or FALSE on timeout 242 */ 243 public int timedWait(Mutex mutex, ref GTimeVal absTime) 244 { 245 // gboolean g_cond_timed_wait (GCond *cond, GMutex *mutex, GTimeVal *abs_time); 246 return g_cond_timed_wait(gCond, (mutex is null) ? null : mutex.getMutexStruct(), &absTime); 247 } 248 249 /** 250 * Waits until either cond is signalled or end_time has passed. 251 * As with g_cond_wait() it is possible that a spurious or stolen wakeup 252 * could occur. For that reason, waiting on a condition variable should 253 * always be in a loop, based on an explicitly-checked predicate. 254 * TRUE is returned if the condition variable was signalled (or in the 255 * case of a spurious wakeup). FALSE is returned if end_time has 256 * passed. 257 * The following code shows how to correctly perform a timed wait on a 258 * condition variable (extended the example presented in the 259 * Since 2.32 260 * Params: 261 * mutex = a GMutex that is currently locked 262 * endTime = the monotonic time to wait until 263 * Returns: TRUE on a signal, FALSE on a timeout 264 */ 265 public int waitUntil(Mutex mutex, long endTime) 266 { 267 // gboolean g_cond_wait_until (GCond *cond, GMutex *mutex, gint64 end_time); 268 return g_cond_wait_until(gCond, (mutex is null) ? null : mutex.getMutexStruct(), endTime); 269 } 270 271 /** 272 * If threads are waiting for cond, at least one of them is unblocked. 273 * If no threads are waiting for cond, this function has no effect. 274 * It is good practice to hold the same lock as the waiting thread 275 * while calling this function, though not required. 276 */ 277 public void signal() 278 { 279 // void g_cond_signal (GCond *cond); 280 g_cond_signal(gCond); 281 } 282 283 /** 284 * If threads are waiting for cond, all of them are unblocked. 285 * If no threads are waiting for cond, this function has no effect. 286 * It is good practice to lock the same mutex as the waiting threads 287 * while calling this function, though not required. 288 */ 289 public void broadcast() 290 { 291 // void g_cond_broadcast (GCond *cond); 292 g_cond_broadcast(gCond); 293 } 294 }