On Thu, Aug 22, 2002 at 03:59:24PM -0400, Chris Darroch wrote: > OK, pursuant to my previous email, here's a stab at an implementation > of proc_mutex_proc_pthread_tryacquire(). Mostly I studied > apr_thread_mutex_trylock() and proc_mutex_proc_pthread_acquire() > to see what they were doing, plus read the man page a bit > on what pthread_mutex_consistent_np() did. > > With luck, the logic should be: > > - Check for non-zero return value. > - If return value is EOWNERDEAD and we're trying to handle consistency > ourselves, call pthread_mutex_consistent_np() and set return > value to zero. > - If return value is EBUSY, make it APR_EBUSY. > - If return value is zero (APR_SUCCESS), set our lock flag. > - Return. > > The proc_mutex_proc_pthread_acquire() function seems to > suck up the EOWNERDEAD return value, setting the curr_locked flag > to 1 and returning APR_SUCCESS, so that's what I made the tryacquire > case do also. > > However, it seems to me that this behaviour, for both functions, > might not be too helpful for callers, since any data they > are protecting with our lock might be in an inconsistent state, > but they'd have no way of determining that from our return value. > Maybe we should invent an APR_EOWNERDEAD value and return that?
You are correct, but we can't invent an APR_EOWNERDEAD unless that semantic is portable, which I don't believe it is. What happens to a mutex right now when the owner dies, on platforms that don't have pthread_mutex_consistent_np()? I'm all for implementing trylock where possible, but I'm not comfortable introducing non-posix/non-portable pthread calls. -aaron
