Ludovic Courtès writes: >> 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’.
I wonder if it's about time that Guile get something along the lines of a well-supported, general event loop system? There's value in having a mainline way to do it; Python has AsyncIO which is gaining a lot of traction... the main advantage being that having an officially supported cooperative event loop (and as a bonus, an official way of working with it nicely with coroutines) permits writing a lot of code in a non-blocking way that's compatible... you can use this non-blocking database wrapper with that non-blocking websocket implementation, for example. This is pretty off-topic from Guix though I guess... maybe it's a conversation for guile-user, or guile-devel. But I'm curious if others have been thinking along these lines. - Chris