Re: Avoiding threads in the daemon

[Ludovic Courtès]

Hi,

Eelco Dolstra <address@hidden> skribis:

> 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.).

Hmm, I’m not convinced about the whole threads-for-convenience approach
à la Java.  (I think the ideal is a single-threaded event loop; of
course we want to avoid IoC, and this is where FRP or monads come in.)

> 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).

Hmm.

> * 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.

Surely.

> * Get the Glibc folks to provide a way to run at-fork handlers with clone().

Hmm.

> Clearly the first option is the easiest.

Yeah.

I think threads are a can of worms anyway and may cause other problems
eventually.

Thanks,
Ludo’.