Hi, Eelco Dolstra <eelco.dols...@logicblox.com> 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’.
