This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: pthread_mutex_trylock does not lock


Robert Collins wrote:
On Thu, 2002-12-05 at 08:33, Christophe Galerne wrote:

NB: PT_MUTEX_NORMAL is not a posix mutex type - it's PTHREAD_MUTEX_NORMAL....
Right that was a typo.

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.

Come to think about it, I'm wondering if there was a policy of having the headers right first then the implementation or if headers and imlpementation
came together. But that's maybe not the right maillist for that. =:-D

Also above
pthread.h(57): #define PTHREAD_MUTEX_INITIALIZER (void *)20
a comment that says that a default MUTEX will be recursive
might avoid some surprise. =:-D
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

Christophe


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]