From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: Hack the (init) system! Date: Fri, 04 Sep 2015 14:08:02 +0200 Message-ID: <87a8t2wfod.fsf@gnu.org> References: <87oahjz05m.fsf@gnu.org> <874mjb0wvm.fsf@netris.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:37723) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZXpms-0003mo-FE for guix-devel@gnu.org; Fri, 04 Sep 2015 08:08:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZXpmm-0001Ur-Jp for guix-devel@gnu.org; Fri, 04 Sep 2015 08:08:10 -0400 In-Reply-To: <874mjb0wvm.fsf@netris.org> (Mark H. Weaver's message of "Thu, 03 Sep 2015 21:57:33 -0400") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Mark H Weaver Cc: guix-devel@gnu.org Mark H Weaver skribis: > ludo@gnu.org (Ludovic Court=C3=A8s) writes: [...] >> I=E2=80=99m tempted to just commit that. There are shortcomings: (1) th= e REPL >> server runs in a thread and threads + fork don=E2=80=99t go together well >> (although in practice dmd only does fork followed by exec, so it=E2=80= =99s OK), > > Unfortunately, it's only okay if the code between fork and exec in the > child process is carefully written to execute only "async-signal-safe" > operations. Right (I was not suggesting that the hack is robus, rather that it=E2=80=99s kinda OK =E2=80=9Cin practice=E2=80=9D, notably because I would only start = it once all the =E2=80=98fork=E2=80=99 calls have been made.) > So, I think we have two choices: > > 1. Avoid threads in dmd, i.e. either refrain from adding this REPL > server feature, or re-implement it in a way that avoids threads. > > 2. Avoid 'primitive-fork' in dmd, which means reimplementing > 'fork+exec-command' in C; reimplementing the code where we currently > use 'primitive-fork' within various guix service definitions; and > documenting that users should never use 'primitive-fork' in their > services. If we choose this route, we should probably disable > 'primitive-fork' somehow, or at least have it issue a stern warning. > > I don't think that we should add a set of features to dmd that will make > it fundamentally unreliable in a way that cannot be fixed. > > What do you think? Agreed, of course. I think #1 is the way to go. Thanks, Ludo=E2=80=99.