I have a program that uses std::process::Command::spawn
, and it produces zombies.
I know very well that the parent process must read out children exit codes, otherwise zombies happen. This is also warned about in Rustdocs for std::process
, and well-explained on SO and the web.
The problem is, subprocesses are identified by pid
s throughout the program; but I don't see a way to construct a Child
referring to known pre-existing pid. Hence I can't call wait()
on it.
From std/process.rs
source, I can guess that crate::sys::process
might expose a directly-callable waitpid()
wrapper I could pass the bare pid_t
integer to. But also I don't feel easy about reaching into internals of Rust stdlib, especially for this kind of mundane reason. Coding it this way doesn't feel right.
Another solution could be, to try to preserve the Child
objects, carry them instead of their pids all over from that spawn()
call to termination handler... which is a long way in this program, and would require a chunk of a refactor. It also feels weird to have a process identifier which can't actually be used as an ID, and instead forces me to carry a complete record with all the other fields.
Can this situation be helped? I'm not terribly familiar with Rust dev-process; do I file an issue framing this as an stdlib defect? Am I missing an alternative way?