Re: [Nix-dev] Avoiding threads in the daemon

[Alexander Kjeldaas]

On Fri, Dec 19, 2014 at 7:20 PM, Eelco Dolstra <address@hidden> 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