From: Harald O. <har...@el...> - 2013-07-25 09:57:53
|
Am 25.07.2013 11:49, schrieb Donal K. Fellows: > On 25/07/2013 08:47, Zoran Vasiljevic wrote: >> Remember that any mutex locked before the fork will be left locked, >> potentially leading to deadlocks. > > We've been down this rabbit hole before. It leads to a place where we > end up saying that we can't do anything because we can't guarantee that > someone doing something perverse won't run into trouble, and that in > turn leaves things known-broken for a significant real use case. I > reject such negativity. > > The only thing we can do is to put things into a known state (i.e., with > known mutexes locked — you can't truly know the state of an unlocked > mutex except by locking it — and with *no* effort spent on unknown > mutexes) and press onwards. After the fork(), we can put the mutex state > back to how it ought to be. > > What I don't know is whether the lock state of mutexes is shared across > the fork as opposed to being duplicated; duplicated is OK, shared is not. Thank you all for the mutex discussion. Alexandre pointed out, that mutexes are copied, not shared. IMHO, all mutexes are ok in their forked state, they just continue. Only the mutexes concerning the notifier thread are not correct, as in the forked process, the thread does not exist in the same state. Due to that, I am in favor of Jans solution to just reset the mutexes linked to the Notifier thread and leave any other as it is. Harald |