fork() doesn't ensure a consistent state of libroot data
|Reported by:||bonefish||Owned by:||axeld|
|Has a Patch:||no||Platform:||All|
When a thread of a multi-threaded team calls fork() other threads could execute critical sections in libroot protected by locks. The protected data might thus be in an inconsistent state in the child team. The locks might appear in a locked state (depending on their implementation) -- ATM they are reinitialized in atfork() hooks. A correct solution would be to register all problematic locks at a central point in libroot and in fork(), before calling the system, acquire them all.