On Mon, Sep 7, 2015 at 12:13 PM, Ludovic Courtès <l...@gnu.org> wrote: > David Thompson <dthomps...@worcester.edu> skribis: > >> This patch resolves an issue I was having when working with containers >> at the REPL, which means it probably presented undetected issues >> elsewhere. > > Calling ‘primitive-fork’ at the REPL is not very useful anyway since you > end up with two Guiles trying to read from the same tty.
Yes, this is true, but it made it glaringly obvious that something was wrong. (match (primitive-fork) (0 (primitive-exit 0)) (pid pid)) ; OK since it exits immediately (match (clone (logior CLONE_NEWUSER SIGCHLD)) (0 (primitive-exit 0)) (pid pid)) ; Broken REPL! >> From 61ebbe55f7f6d4d4eb42db957d6fc7b4eaf282a6 Mon Sep 17 00:00:00 2001 >> From: David Thompson <dthomps...@worcester.edu> >> Date: Sat, 5 Sep 2015 14:10:08 -0400 >> Subject: [PATCH] build: container: Use the same clone flags as fork(3). >> >> The intent is to make 'clone' behave a lot more like 'primitive-fork', which >> calls clone(2) with SIGCHLD, CLONE_CHILD_CLEARTID, and CLONE_CHILD_SETTID >> flags. Notably, running 'clone' at the REPL without these flags would break >> the REPL beyond repair. >> >> * guix/build/syscalls.scm (CLONE_CHILD_CLEARTID, CLONE_CHILD_SETTID): New >> variables. >> * gnu/build/linux-container.scm (namespaces->bit-mask): Add >> CLONE_CHILD_CLEARTID and CLONE_CHILD_SETTID to bit mask. > > Looking at clone(2) and libc, I’m guessing that without these flags, the > child would have a wrong idea of its thread ID, which in turn may cause > all sorts of problems, right? Yes, that seems to be the case. I was always a little suspicious about not using the same clone flags as fork, and I finally ran into a case where it made a difference. > LGTM. Pushed, thanks! - Dave