Re: Preliminary proposal for a process library Lassi Kortela 19 Aug 2019 11:46 UTC
> https://bitbucket.org/cowan/r7rs-wg1-infra/src/default/ProcessesCowan.md 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 <https://htmlpreview.github.io/?https://github.com/lassik/scheme-os-survey/blob/master/data.html> and be in a better position to comment on the details. Help gratefully accepted.