I just found that in some weird situations, if
rust-analzyer panic / crash accidentally, the child process spawned for proc-macro did not be killed in Windows. I know it is the default behavior for Windows program. I can't reproduce this in linux, but I doubt it might happens there too.
I know https://stackoverflow.com/questions/53208/how-do-i-automatically-destroy-child-processes-in-windows is a proper solution for this problem in Windows. but it will make the code complicated as it is platform specific, and I don't know it is worth or not.
This feels like the kind of thing that should be handled by a crate in the ecosystem
"spawn a child process with automatic cleanup"
If you assume unwinding, storing the handle somewhere and terminating the child on
Drop is enough on any platform
Even I kill the parent process externally ?
TL;DR of duct's info page is that job objects seem to solve the problem proposed (correct transitive child process cleanup) but *nix doesn't have a good solution yet
And killing the process externally would not be able to assume unwinding
I think if we panic, we should kill the child process (in Drop). If we crash abnormaly (like via sigkill) I don't feel like it is worth it to clean up the child. Although this is possible, cargo implements this here: https://github.com/rust-lang/cargo/blob/5b620dc044e8999e6bc0193f9e037c4618519547/src/cargo/util/job.rs
But, I think that we should add an
JChild struct to
stdx::process, which kills the child on drop.
@matklad iirc, the job thing on windows is just for ctrl+c as well
From the doc comment:
Job objects have a mode of operation where when all handles to the object are closed it causes all child processes associated with the object to be terminated immediately.
I think this means that any way of exiting the process will kill all child processes.