Ion Gaztañaga wrote:
Vicente Botet Escriba wrote:
Edouard A. wrote:
The answer to your question is "an exception will be thrown" since the call will return "EOWNERDEAD".
Generally speaking when a thread terminates while holding a mutex, the mutex is considered abandoned and shared resources protected by the mutex are in an undetermined state. Hope you like quantum physics. ;)
if this is the case, what do you think about adding a kind of resource manager that will ensure all the shared resources are released (and in particular the interprocess::mutex are unlocked) on a cleanup phase just before diing?
There is no guarantee at all. POSIX does not guarantee EOWNERDEAD if you don't use robust mutexes, which is now an option in POSIX 2008 (O'll try to add it ASAP but adding robust mutexes has some interface problems) but is not mandatory.
Adding a resource manager is not trivial, it needs to periodically check if processes are alive and that's not easy. Interprocess does not offer any guarantee that the underlying OS does not offer.
Best,
Ion _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hi, what kind of interface problems have adding robust mutexes? Do you mean that you plan to use robust mutex when available? Should this be an option? My initial question was, on which state a locked interprocess mutex is when the owning process dies (with the current implementation)? is it locked? unlocked? it is undefined? How an application can recover from this situation? Best, Vicente -- View this message in context: http://www.nabble.com/-interprocess--locked-mutex-and-process-killed-tp22671... Sent from the Boost - Dev mailing list archive at Nabble.com.