Mark H Weaver <m...@netris.org> skribis: > l...@gnu.org (Ludovic Courtès) writes:
[...] >> 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. Right (I was not suggesting that the hack is robus, rather that it’s kinda OK “in practice”, notably because I would only start it once all the ‘fork’ 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’.
