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 }