"kjtsanaktsidis (KJ Tsanaktsidis) via ruby-core" <ruby-core@ml.ruby-lang.org> wrote:
2. Programs doing `waitpid -1` are widely deployed, it would be good if, when writing gems, there were APIs we could use which offer better isolation and composibility than the classic unix APIs, so that our gems work no matter what their containing processes are doing.
My thinking on this issue is camp 2. Like it or not (and really, I don't like it), `waitpid -1` has been part of the unix way of doing preforking worker pools since approximately forever, and it would be good if programs such programs could use gems without carefully checking whether they spawn any subprocesses in their implementation.
Same here. I think the process.c stuff I worked on for MJIT can be extended easily to support registering per-PID callbacks: Process.wait(pid) { |wpid, status| ... } (But I'll let you or somebody else interested implement it)
Perhaps some more data needs to be gathered on just how common `waitpid -1` actually is? If people think this is something that moves the needle on this discussion, I'm happy to do some research on the topic.
Pretty common if Process.waitall exists. Breaking any common use case is unacceptable to me. But I'm of a minority opinion.