yes, check the original code -- if NsLockFree (Ns_MutexDestroy in 3.x) can't destroy the mutex b/c another thread is using it, it calls NsThreadFatal. Here's Jim's "official" explanation as to why:
"I think it's fine that NsThreadFatal kills nsd - design plan has always been that thread errors are fatal errors, i.e., process must be killed and fixed. As for the thread destory thing, idea is to use proper syncronization (e.g., Ns_ThreadJoin) to ensure when it's possible to destroy a mutex. Not doing so seems like sloppy code."
My response, which was ignored (twice) in private email, is that
- there is no interface to check if another thread is using a mutex, so how can it be a programmer error if we don't provide a way to avoid it? (and a quick examination of the pthread functionality should convince you that we don't provide this because it's not possible to do so at that level.)
- even if we jump through totally unnecessary bookkeeping hoops so that thread A, who wants to destroy the mutex, knows the thread id of B, who is currently using it, there is no guarantee that ns_thread wait on B, followed by destroy, would get the mutex before thread C, who is blocking on ns_mutex lock.
Really I have a hard time picturing a real-world situation where Jim's attitude makes sense.
