pthread_mutex_trylock does not lock
Robert Collins
rbcollins@cygwin.com
Wed Dec 4 23:34:00 GMT 2002
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.
---
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://cygwin.com/pipermail/cygwin/attachments/20021204/b98c1b16/attachment.sig>
More information about the Cygwin
mailing list