Subject: Re: pthread_mutex_trylock does not lock
From: Robert Collins <[email-masked]>
To: Christophe Galerne <[email-masked]>
Cc: cygwin <[email-masked]>
Date: 06 Dec 2002 04:34:11 +1100

On Thu, 2002-12-05 at 10:47, Christophe Galerne wrote:

> > Or you could check the return value from pthread_mutexattr_settype and
> > see that it returns EINVAL.
> 
> The thing is it's not really an invalid value for 'type' in the call.
> Maybe it would be better to break the compilation of programs that
> expect this value rather than have the developpers debug their applications
> before figuring it out.

With all due respect, any program that doesn't log and quit with such an
error - ie one that requires debugging - is already broken. Good
programs *do* check error codes. And they *do* set the mutex type they
need if the behaviour for PTHREAD_MUTEX_DEFAULT does not suite.

> > Look at pthread.h:53 and pthread.h:58. DEFAULT is mapped to RECURSIVE 
> 
> That's a good point.
> Onather solution that might be considered more elegant would be to
> rearrange the defines to make the default behavior self-explanatory.
> Ex.
> #define PTHREAD_MUTEX_RECURSIVE 0
> #define PTHREAD_MUTEX_ERRORCHECK 1
> #define PTHREAD_MUTEX_NORMAL 2
> #define PTHREAD_MUTEX_DEFAULT PTHREAD_MUTEX_RECURSIVE

Good suggestion, next time I'm tweaking the file I may just do that. OR:
you could submit a patch:}.

Rob

-- 
---
GPG key available at: http://users.bigpond.net.au/robertc/keys.txt.
---