l...@gnu.org (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