[lxc-devel] Working with glibc (PID/TID caches).

[Eric W. Biederman]

While talking about pain points there is a very large one.  In short
pthreads break fork().

At least according to the open group after fork (when more than one
pthread is active) and by extension clone(CLONE_NEW...) it is only safe
to call async-signal-safe functions.  The rationale being that some
other thread might have possibly held a lock during fork.

Which means it becomes extraordinarily difficult to safely set up
and read /proc/mounts etc, etc.  Because malloc and huge portions of
supporting code are now verbotten.

Several of the namespaces require a non-trivial amount of set-up work
from within.  The mount namespace requires calling mount, umount, and
pivot_root.  The network namespace requires making netlink calls over
sockets.

The work arounds involving multi-process synchronization and setns after
fork are quite ugly.

It would be nice if at least malloc and C++ new were safe (and
documented as safe) after fork in a pthread environment.  That would go
a long ways to allowing running interesting set up code without having
to jump through hoops.

Eric