Announcing ClonableChild to make it possible to kill child processes while waiting for them

announcements
1

https://crates.io/crates/clonablechild

I needed to spawn a long running child process in my Rust program and both monitor it for termination and being able to kill it on events. Child processes can be spawned using std::process::Command. The problem is that both wait() and kill() on the Child object take &mut self. Thus it is not possible to have one thread wait for the process and have another thread kill it on some event.

This new crate fixes that problem by introducing an into_clonable() method on Child that returns a ClonableChild that act and behaves just like a Child, only difference is that it can be cloned and the methods on it only require &self, not &mut self.

Feedback more than welcome! How can this be improved?

TODO:

  • Implement wait_with_output
  • Add an shutdown method that will use SIGTERM instead of SIGKILL and something similar for Windows.
2

I wonder why Child::wait and Child::kill take &mut self? Maybe this should be a change upstream?

3

Because both modify the Child's internal state and thus are not thread-safe?

4

This should be completely safe if I'm not missing something. No reason that I know of why sending a SIGKILL or a TerminateProcess at the same time as something is waiting for the process would be bad.

upstream could change it if they just put a Mutex around some of the internal data, such as the status inside std::sys::unix::Child. I might propose that later, depending on the feedback on, and the usage of this crate.

2 Likes
5

What happened to this crate? It seems to have been yanked. Perhaps it no longer works due to changes in the standard library?

6

The reason was posted on the repository readme. Would be nice if that deprecation notice could be displayed by crates.io as a "reason this crate was yanked" field.

DEPRECATED: This crate has been deprecated and yanked from crates.io. The problem it solves is solved in a better way by the shared_child crate. See this issue for more information.

7

I yanked it because shared_child did more or less the same thing and I think the ecosystem is better off with one working solution than multiple ones where a few might be less well maintained than others. See the top of the readme for more information: https://github.com/faern/clonablechild