Re: [boost] [interprocess] leaked named mutexes

Subject: Re: [boost] [interprocess] leaked named mutexes
From: Kim Barrett (kab.conundrums_at_[hidden])
Date: 2013-03-07 14:16:47

On Mar 7, 2013, at 1:21 PM, Jonathan Wakely wrote:
> Tricky indeed, I've been trying to work out how to map robust mutexes
> to the C++11 Mutex concepts, and have so far decided that calling
> robust_mutex.lock() or robust_mutex.try_lock() should throw an
> exception (with errc::state_not_recoverable) if the owner has died,
> even though C++11 says try_lock() is non-throwing.

I think that demonstrates that robust mutexes are not models of the C++11 Mutex concepts.

> Handling the
> EOWNERDEAD case has to be requested explicitly by the user by passing
> a special value of type robust_t:

My approach to using robust mutexes does not attempt to treat them as models of the C++11 Mutex concept.  Instead, there are now locking operations associated with them which *require* a handler function that gets invoked on EOWNERDEAD.  This approach filtered up to condition variables too; can't use C++11 / boost.thread condition variables with these robust mutexes, because of the requirement for a handler for EOWNERDEAD.

I thought about providing C++11 Mutex-like operations to allow these robust mutexes to be used like ordinary mutexes, but ultimately decided there was no real use-case for that, since the whole point of a robust mutex is to support EOWNERDEAD handling.