guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Hack the (init) system!


From: Mark H Weaver
Subject: Re: Hack the (init) system!
Date: Thu, 03 Sep 2015 21:57:33 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

address@hidden (Ludovic Courtès) writes:

> We’ve all been talking about it for some time: a REPL server in dmd!
>
> This can be done by changing zero lines in dmd:

Cool hack!

> I’m tempted to just commit that.  There are shortcomings: (1) the REPL
> server runs in a thread and threads + fork don’t go together well
> (although in practice dmd only does fork followed by exec, so it’s 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.

  http://pubs.opengroup.org/onlinepubs/9699919799/functions/fork.html

I don't think we can ensure this unless the fork, exec, and everything
in between is carefully written in C.  This is not currently the case in
dmd.

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?

      Mark



reply via email to

[Prev in Thread] Current Thread [Next in Thread]