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. ---
signature.asc
Description: This is a digitally signed message part
