guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Shea Levy
Subject: Re: [Nix-dev] Avoiding threads in the daemon
Date: Fri, 19 Dec 2014 18:41:35 +0000

Can't you unshare in the parent then setns back after fork?



> On Dec 19, 2014, at 18:20, 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.
> 
> -- 
> Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/
> _______________________________________________
> nix-dev mailing list
> address@hidden
> http://lists.science.uu.nl/mailman/listinfo/nix-dev



reply via email to

[Prev in Thread] Current Thread [Next in Thread]