site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com pthread deadlock detection is optional in the standard. Even something as simple as two consecutive pthread_mutex_lock() calls will hang instead of returning EDEADLK. (And given the amount of code in the world that fails to check the return value, that's probably a good thing.) % nm /usr/lib/libSystem.B.dylib | grep UNIX2003 | wc -l 174 -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... On May 28, 2009, at 12:16 PM, Wade Tregaskis wrote: Unfortunate but true! Are there any options that can be turned on to enable all the optional debug parts? I'm thinking something like the malloc environment variables, like MallocScribble. Otherwise, I'm going to have to roll my own test code into the wrapper that I'm writing, but that will be significantly less efficient than using a prebuilt debug library. Not that I'm aware. For mutexes you can specify an explicit attribute at initialisation time, with the type set to PTHREAD_MUTEX_ERRORCHECK (see man pthread_mutexattr_settype), which should enable deadlock detection. Alas, rwlocks don't have an equivalent attribute setting. Looking at the Darwin source, iff pthreads is compiled with __DARWIN_UNIX03 defined, then some deadlock detection is enabled - such as when trying to take a read or write on the lock if you already hold it for writing - but I don't know if it's compiled that way on Mac OS X. There are multiple compilation environments available; see the comments in <sys/cdefs.h> for details. The internal tag that you're looking at (__DARWIN_UNIX03 ) is a derived tag and should not be used directly; internally, it just means "UNIX 2003 conformat APIs plus Apple APIs not covered by the UNIX standard". The answer is that if you are targeting Leopard or later using supported development environments for Leopard or later, you're going to get the UNIX conformant behaviour by default, which will get you the checks you're wanting to get, and get you the error return. For any UNIX conformant system where the behaviour is "implementation defined", you should probably avoid using the interface the way you're trying to use it, since it's going to render your code non-portable to any implementation that defines the behaviour differently. However, for any UNIX implementation which has passed certification (like Mac OS X Leopard), you can find out what the implementation does with the implementation questionnaire responses, which is on file with The OpenGroup, <http://www.opengroup.org>. The lack of checking is required for binary backward compatibility, to not change the behaviour of programs which have, for reasons of their own, written code which deadlocks, and, rather than eliminating the deadlocks, they've come up with some mechanism of their own for dealing with them (like alarm()'ing out of the blocking call), and effectively now depend on the deadlock behaviour. Given that you are using POSIX interfaces, you should probably be using that compilation environment, but I can't tell you to target only Leopard or later with your code, that'd have to be your decision. If you don't, however, you'll either have to avoid causing deadlocks by writing standards compliant code, or you'll have to come up with your own coping mechanism for dealing with them, like other have with their pre-Leopard code. When we did the standards conformance effort, there were a lot of places where we had to maintain the old behaviour for binary backward compatibility, and provide the new behaviour in a different compilation environment, to avoid introducing binary compatibility issues. In LibSystem alone, there are 174 cases of this: Obviously, there are also cases where frameworks reflect untranslated (raw UNIX) types or values through their own APIs, and those also have similar issues that had to be addressed by their maintainers. Yeah, it's kind of annoying, if you are only coming to the UNIX table now, instead of years ago when the changes first went in, and are wanting to support OS releases from years ago without multiple binaries, but if you don't take the standards-compliant compilation environment, you don't get the protections and behavioural guarantees the environment offers you. I like to think of it as additional incentives for making the switch to standards compliant code. This email sent to site_archiver@lists.apple.com