You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
when using interprocess shared memroy, there are about two locks. one is the internal mutex_family used by boost for managing the sharedmemory in MemoryAlgorithm, one is the user's one for synchronation. both mutex will cause deadlock, when process crash. How do you think about it.
the linux provide pthread_mutexattr_setrobust, but the interprocess module do not provide the interface, eg. interprocess:scoped_lock's lock's return value is void instead of int, which could be compare with EOWNERDEAD.
Activity
Added posix robust mutex implementation to allow subsequent mutex loc…
Changed to use posix robust mutex to allow subsequent mutex lock can …
Fixes boostorg#65 ("Robustness of the interprocess mutex") and fixes b…