Re: Preliminary proposal for a process library Lassi Kortela 19 Aug 2019 11:46 UTC


Once again, thank you for drafting yet another document! IMHO both the
approach and details are quite good already.

I would still slightly favor an opaque not-yet-launched-process object
but the plist approach is a pretty good approximation.

Have to think some more about (process-wait ...) & co. A unified polling
procedure to poll all kinds of objects is really convenient for users
and probably for implementors as well. Is a process-only poller
trivially implementable as a special case of a generic poller? Probably.

> This is a fairly high-level library based on the Python 3 subprocess
> library.  I think it is better to have this library or something like it
> rather than a low-level library, because safe implementation is tricky.

100% agree with the approach. Let's try to hide the footguns in the
implementation so the inevitable problems can be fixed in one place. We
just debugged a mysterious problem for a whole day with Marc that turned
out to be a MacOS poll() bug. Such OS bugs are apparently quite common.

> As an example, SIGINT must be ignored while waiting for a child process,
> otherwise both the child and the parent will receive the signal.  This
> is not something that Scheme programmers should need to know about.

Very much agreed! Also threads. And life would not be truly complete
without the joyous interplay of signals and threads.

I'll complete the survey at
and be in a better position to comment on the details. Help gratefully