Le vendredi 07 décembre 2007 à 12:17 +0100, Bruno Haible a écrit :
Yoann Vandoorselaere wrote:
I'm worried about lock initialization. If initializing a mutex fail, the
application should be allowed to handle it gracefully.
In all cases I know of, a lock initialization is nothing more
Yoann Vandoorselaere wrote:
I'm worried about lock initialization. If initializing a mutex fail, the
application should be allowed to handle it gracefully.
In all cases I know of, a lock initialization is nothing more than a memcpy.
I'm not worried about it.
Some applications provide threads
Yoann Vandoorselaere wrote:
I don't know what a better handling
of pthread_* function failures could look like. What do you propose?
Any reason why you don't simply return error values returned by
pthread_* functions (which should set errno appropriately), and let the
caller possibly
Le mardi 04 décembre 2007 à 09:46 +0100, Bruno Haible a écrit :
Yoann Vandoorselaere wrote:
I don't know what a better handling
of pthread_* function failures could look like. What do you propose?
Any reason why you don't simply return error values returned by
pthread_* functions
Le vendredi 30 novembre 2007 à 16:41 +0100, Bruno Haible a écrit :
Yoann Vandoorselaere wrote:
The gl_recursive_lock_init() macro used for the pthread backend never
set the mutex attribute to be recursive. The end result is that a
'standard' mutex is created, which will deadlock on
Hi,
The gl_recursive_lock_init() macro used for the pthread backend never
set the mutex attribute to be recursive. The end result is that a
'standard' mutex is created, which will deadlock on recursive use. A
patch is attached that fixes this issue.
Additionally, lock.h make use of the abort()
Yoann Vandoorselaere wrote:
The gl_recursive_lock_init() macro used for the pthread backend never
set the mutex attribute to be recursive. The end result is that a
'standard' mutex is created, which will deadlock on recursive use. A
patch is attached that fixes this issue.
Indeed. Thanks for
