On 2/1/06, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote: > WAIT_ABANDONED, according to these notes, is a signal that the owning thread > has closed, and IIUC Win32 kernel will choose a new owner as a 'next step'. > > http://issues.apache.org/bugzilla/show_bug.cgi?id=38410 > > What happens on unix when the owner 'dies'?
in general: kernel picks a new owner unbeknownst to us: exception: with cross-process pthread mutexes, the ownership is toast forever and ever, thus waiters on the mutex are hung exception to exception: with cross-process pthread mutexes on Solaris 8 and above, APR uses a non-portable API which results in another thread seeing a non-portable return code, and then APR does the magic handshake with the kernel and returns APR_SUCCESS to the caller > Can we map this to some consistent results from the apr call to > >apr_proc_mutex_[try]lock()? If the caller's explanation of WAIT_ABANDONED is correct, then the caller's suggested loop looks good for apr_proc_mutex_lock(). I didn't realize there was apr_proc_mtuex_try_lock(). That should return the didn't-get-the-lock retcode.
