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.) Wade _______________________________________________ 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... 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. This email sent to site_archiver@lists.apple.com