fork() doesn't ensure a consistent state of libroot data

[bonefish]

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.

[korli]

@bonefish, OK to close?

[bonefish]

The ticket is quite general, but since POSIX restricts, what can be done after fork() anyway, I guess the status quo -- the runtime loader and the memory allocator being safe -- should be OK.