Add std::process::Child::terminate as an alternative to std::process::Child::kill

[peterdelevoryas]

I have frequently used std::process::Child::kill and/or kill_on_drop(true) since it's in the standard library, but I think it's probably better for people to use SIGTERM if they can. There's lots of use-cases where a subprocess might want to do some last-minute stuff before exiting, right?

Many cleanup steps, like closing files, are handled in Linux automatically, but sometimes a process might want to cleanup something through the network (logging, shared resources between machines).

Also, the standard Linux utility kill sends SIGTERM by default, and I've always understood that this is because SIGKILL should only be used if a process doesn't respond to SIGTERM.

The Python standard library module subprocess has some precedent for this: it provides kill, terminate, and send_signal. [1] I figure we could start by adding terminate, because that's probably the next-most-common signal that people use.

Let me know what you guys think: my understanding from the dev-guide is that making API Change Proposals is optional, and this is a pretty small change, so I figured I'd just send a PR.

By the way, I did consider implementing this as an extension to the Linux ChildExt, since SIGTERM is only applicable on Unix, but the Python library avoids this complexity by just implementing terminate() the same way as kill() on Windows and other platforms. I figured we might as well just follow the Python standard library here, it seems reasonable.

[1] https://docs.python.org/3/library/subprocess.html#subprocess.Popen.terminatehttps://docs.python.org/3/library/subprocess.html#subprocess.Popen.terminate

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @joshtriplett (or someone else) soon.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[the8472]

See rust-lang/libs-team#97 and specifically rust-lang/libs-team#97 (comment) for an accepted API proposal in this area.

[peterdelevoryas]

See rust-lang/libs-team#97 and specifically rust-lang/libs-team#97 (comment) for an accepted API proposal in this area.

Oh awesome, has nobody implemented this yet? I'll take a shot at it, tl;dr send_signal(i32) on a unix extension trait right?