Add `kill_process_group` to Unix `ChildExt`

[jmillikin]

Proposal

Problem statement

The CommandExt::process_group builder function can be used to assign a process group to a newly spawned subprocess. There is no corresponding method on ChildExt to send signals to the process group with killpg().

Motivating examples or use cases

I want to spawn subprocess trees with std::process and be able to terminate them with SIGINT / SIGKILL.

Solution sketch

Add kill_process_group to std::os::unix::process::ChildExt:

trait ChildExt {
    /// Forces the child's entire process group to exit.
    /// If the child has already exited, Ok(()) is returned.
    fn kill_process_group(&mut self) -> Result<()>;
}

The killpg() function is part of POSIX, so this can be a part of the Unix ChildExt instead of OS-specific ChildExt.

The ChildExt trait currently has an unstable method for sending arbitrary signals to the child. Since kill_process_group wraps killpg() it may be worth adding a new method to the unix_send_signal unstable feature:

trait ChildExt {
    /// like send_signal() but calls `killpg()` instead of `kill()`
    fn send_process_group_signal(&self, signal: i32) -> Result<()>;
}

Alternatives

Do nothing, in which case users have to either depend on libc or do their own extern "C" killpg declaration.

Links and related work

https://doc.rust-lang.org/std/os/unix/process/trait.CommandExt.html#tymethod.process_group

https://doc.rust-lang.org/std/process/struct.Child.html#method.kill

https://doc.rust-lang.org/std/os/unix/process/trait.ChildExt.html

https://pubs.opengroup.org/onlinepubs/9699919799.orig/functions/killpg.html

What happens now?

This issue contains an API change proposal (or ACP) and is part of the libs-api team feature lifecycle. Once this issue is filed, the libs-api team will review open proposals as capability becomes available. Current response times do not have a clear estimate, but may be up to several months.

Possible responses

The libs team may respond in various different ways. First, the team will consider the problem (this doesn't require any concrete solution or alternatives to have been proposed):

• We think this problem seems worth solving, and the standard library might be the right place to solve it.
• We think that this probably doesn't belong in the standard library.

Second, if there's a concrete solution:

• We think this specific solution looks roughly right, approved, you or someone else should implement this. (Further review will still happen on the subsequent implementation PR.)
• We're not sure this is the right solution, and the alternatives or other materials don't give us enough information to be sure about that. Here are some questions we have that aren't answered, or rough ideas about alternatives we'd want to see discussed.

[nia-e]

We discussed this in today's libs-api meeting and are happy with this; the docs for this should probably mention how to put the spawned child into a different pg (calling .process_group()). Thanks!