Re: Avoiding threads in the daemon

[Alexander Kjeldaas <ak@formalprivacy.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1611 bytes --]

On Fri, Dec 19, 2014 at 7:20 PM, Eelco Dolstra <eelco.dolstra@logicblox.com>
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

[-- Attachment #1.2: Type: text/html, Size: 2073 bytes --]

[-- Attachment #2: Type: text/plain, Size: 149 bytes --]

_______________________________________________
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev