Eelco Dolstra eelco.dols...@logicblox.com skribis:
On 19/12/14 19:20, Eelco Dolstra wrote:
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).
This has been implemented in
Hi,
On 19/12/14 19:20, Eelco Dolstra wrote:
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).
This has been implemented in bd0f362d2fad1dd5f28e762011888b5eabd21280.
--
Nix commit 524f89 changed libstore to use fork + unshare instead of
clone(2). The problem is that, in doing so, it also removed use of
CLONE_NEWPID and thus, (1) the build process no longer has PID 1, and
(2) build processes end up in the global PID space.
Adding CLONE_NEWPID to the unshare(2)
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
Can't you unshare in the parent then setns back after fork?
On Dec 19, 2014, at 18:20, Eelco Dolstra eelco.dols...@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
Hi,
On 19/12/14 19:41, Shea Levy wrote:
Can't you unshare in the parent then setns back after fork?
In a multi-threaded program, that sounds incredibly racy :-)
(Though it's not clear to me whether unshare() works on the current process or
the current thread. Manpage says process...)
--
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
On Fri, Dec 19, 2014 at 10:31 PM, Ludovic Courtès l...@gnu.org wrote:
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.)
It is
On Fri, Dec 19, 2014 at 7:20 PM, Eelco Dolstra eelco.dols...@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
