OSSubprocess reaps processes that it did not spawn #76
Comments
janvrany
added a commit
to janvrany/pharo-hacks
that referenced
this issue
Aug 22, 2023
...rather than Mariano's `OSSubprocess` package. The problem is that `OSSubProcess` reaping logic assumes that all processes are spawned by it so it may (does) reap processes spawned by LibUnix. This commit makes `OSProcess` compatibility class to use `LibUnix` to avoid this problem and throw an error is OSSubProcess is loaded. A proper fix would be to change `OSSubprocess` to only reap processes it has spawned (see [1]) [1] pharo-contributions/OSSubprocess#76
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
OSSubprocess' process reaping logic reaps all child processes, not only those that it has spawned (that is, processes spawned by means of OSSubprocess). Therefore is may happen (does happen) that it does reap processes spawned by some other means (for example, manual calls to
posix_spawn()) making OSSubprocess essentially incompatible (unusable) with any code that spawns processes.I'd argue the code should be changed to only reap processes it has spawned - that's not a big deal as it keeps track of spawned processes anyways. So instead of
waitpid(-1,...)callwaitpid()for each process (it has spawned).While at it, it is not necessary to have reaper process running when there are no outstanding live child processes.
The text was updated successfully, but these errors were encountered: