On Fri, Dec 19, 2014 at 7:20 PM, Eelco Dolstra wrote: > Hi, > > On 18/12/14 17:32, Ludovic Courtès wrote: > > > Thus, I think Nix commit 49fe95 (which introduces monitor-fd.hh, which > > uses std::thread just for convenience) should be reverted, along with > > the subsequent commits to that file; then commit 524f89 can be reverted. > > I really don't want to get rid of threads because they're useful and I > want to > use them more in the future (e.g. build.cc would be much simpler if it used > threads rather than the current event-driven approach; nix-daemon could > handle > client connections with a thread rather than a process; etc.). > > I see a few ways to get PID namespaces back: > > * Do a regular fork followed by clone(... | CLONE_NEWPID | CLONE_PARENT) > (after > which the intermediate process can exit). > > * Call setuid/setgid via syscall() to bypass the locking in the Glibc > wrappers. > However, there might be other problematic functions so this is not a great > solution. > > * Get the Glibc folks to provide a way to run at-fork handlers with > clone(). > > Clearly the first option is the easiest. > > There is a 4th solution - use a fork()-service. What you do is you fork() a specific child, the fork()-service, when you start your process, before any mutex is held and while you control the full state of your program. You then communicate with this service using pipes, or your favorite IPC mechanism. The fork()-service never starts any thread, and can safely fork off any child you need. Alexander