Amend RFC 517: Add material on std::process

[aturon]

The IO reform RFC is being split into several semi-independent pieces, posted as PRs like this one.

This RFC amendment discusses std::process.

Rendered

[abonander]

Can Child include a signal_interrupt() method that sends SIGINT for processes that can exit nicely with Ctrl-C? Or at least include other signal constants where the signal function is going that so that it doesn't require importing them from libc. 😄

It would be nice (if a bit verbose) if the stdin, stdout, stderr fields were Box<Writer + Send + Clone> because one of the boons of the current API is that the PipeStreams can be cloned and sent to another thread for reading, whereas the new API seems to complicate matters by requiring shared references or moves.

[alexcrichton]

I think this was mentioned on the previous RFC, but it may be better to use concrete types here to allow addition of extension traits for platform-specific APIs (such as getting the file descriptor on unix).

[alexcrichton]

Taking another look at the windows implementation, it looks like the only common denominator is signal_kill as both exit/kill are canonicalized to TerminateProcess.

The signal_exit function may wish to live on a unix extension trait for now, and we can perhaps add a windows implementation at a future date.

[jminer]

Since Windows doesn't really have signals, I would like signal_kill renamed to kill. Seeing any reference to signals on Windows seems foreign to me.

[nagisa]

signal_kill renamed to kill

+1 for that another bikeshed colour.

[nodakai]

@alexcrichton It's fine to map SIGKILL to TerminateProcess(), but the common strategy to port SIGINT/SIGBREAK to Windows seems to be to use Win32 API GenerateConsoleCtrlEvent(). My understanding is that cmd.exe calls this API when we hit Ctrl-C on it. What's called "console event" in Win32 API also supports installation of arbitrary "handlers." The drawback is it is restricted to processes sharing the same "console."

See also:

• https://github.com/ruby/ruby/blob/master/win32/win32.c#L3746
• https://github.com/python/cpython/blob/master/Modules/posixmodule.c#L8965

[alexcrichton]

Oh nice, thanks for the pointers @nodakai! The restriction about processes sharing the same console is a little worrying, but I think I'd be fine with providing both variants with this semi-close equivalent.

I'd also be fine tweaking the names, @jminer has a good point that "signal" is inherently unix-biased.

[alexcrichton]

@cybergeek94

Can Child include a signal_interrupt() method that sends SIGINT for processes that can exit nicely with Ctrl-C? Or at least include other signal constants where the signal function is going that so that it doesn't require importing them from libc. 😄

Indeed! The plan here is to move these unix-only functions into an extension trait inside of std::os. The module and/or trait could make it more convenient than importing from libc certainly.

It would be nice (if a bit verbose) if the stdin, stdout, stderr fields were Box<Writer + Send + Clone> because one of the boons of the current API is that the PipeStreams can be cloned and sent to another thread for reading, whereas the new API seems to complicate matters by requiring shared references or moves.

I think this came up on the original RFC, but I've recommended that we move to concrete types instead of trait objects to allow future extensions to be added to them in the future (such as cloning).

[nagisa]

Would be nice if this had the similar API as Thread. i.e. keep spawn which spawns a detached process and add scoped which creates a bound/attached process that you can detach any time later.

[alexcrichton]

This form of detached actually has a somewhat different semantic meaning than the detached for threads, which is good to point out! For threads you can simply choose at some point during their lifecycle to detach, but for processes there's 2 decisions to make:

1. When spawning, the detached flag affects how the child process is spawned.
2. When dropping a Child, whether or not to wait() for the child.

I think that the use case of spawning threads and processes is different enough to keep the APIs different, but we may want to explore various names.

[d3zd3z]

+1 on the std connectors inheriting by default for many invocation cases.

One problem I currently have (that looks unchanged) is that all of the fields of Command are private, and the construction methods are fairly limited. It works ok for code just building a simple command. However, for example, I want to have a method in my code that will possibly augment a command by running it with sudo. Currently there isn't any easy way of doing this, because the fields are private. Perhaps there could be a way of accessing or manipulating the command and argument data. This might also be solvable with the proposal being discussed elsewhere to allow outside impls to access private fields if desired.

[quantheory]

s/we/will/

[quantheory]

This is missing the final backtick on Option<i32>.

[quantheory]

s/ProcessOuptput/Output/

[kjpgit]

do you mean &mut self?

[Stebalien]

As far as I can tell, this proposal doesn't allow for piping directly from one Child to another. Is there any reason the the Stdio enum can't have a constructor that takes a PipeStream?

[alexcrichton]

@Stebalien The outline of this RFC is largely geared towards categorizing today's implementation as well as ensuring that it has ample room to grow in the future. For example today piping from one child to another is difficult to do (requires mucking around with raw file descriptors).

That's not to say that this RFC is saying it can't be done, however. The modifications to the StdioContainer interface as well as using a concrete type for the input/output streams in Process should allow for future expansion to this form of API. You would, for example, request that stdout becomes a pipe, and then you would consume that pipe by passing it to another Command to use as its own stream (for example). These additions are all backwards compatible to make in the future.

[Stebalien]

@alexcrichton got it. Thanks.

[aturon]

All: I've updated this RFC with a few minor fixes. The only substantial change is to not use trait objects for stdin and friends, but instead to use a newtyped reader/writer value to hide the implementation details.

As to reading data out of Command, that should be much more feasible now that we're moving to OsString.

Overall, there hasn't been a ton of feedback here, but I think that's largely because the current APIs are working well. This RFC will come up for a decision in the near future so if you have more feedback, please leave more comments!

[l0kod]

The detached() set a new session for the process but there is no way to change the controlling terminal (e.g. setsid -c). A simple approach would be to add a new function for this feature.

However, a more flexible approach would be to add a pre-execution closure to the Command. This could allow to replace uid(), gid() and detached() (and maybe more) with something like:

impl Command {
    fn prepare<'a, T>(&'a mut self, prepare: T) -> &'a mut Command
        where T: FnOnce() -> IoResult<()>, T: Send + 'a {…}
}

[kjpgit]

running arbitrary code after a fork is not thread safe.

On Sat, Feb 7, 2015 at 7:09 PM, Mickaël Salaün notifications@github.com
wrote:

The detached() set a new session for the process but there is no way to
change the controlling terminal (e.g. setsid -c). A simple approach would
be to add a new function for this feature.

However, a more flexible approach would to be able to add a
pre-execution closure to the Command. This could allow to replace uid(),
gid() and detached() (and maybe more) with something like:

impl Command {
fn prepare<'a, T>(&'a mut self, prepare: T) -> &'a mut Command
where T: FnOnce() -> IoResult<()>, T: Send + 'a {…}
}

—
Reply to this email directly or view it on GitHub
#579 (comment).

[l0kod]

Is there any way to execute some safe code after a fork? A pre-exec hook would be very handy.

[l0kod]

Well, I think a pre-exec hook would be unsafe anyway, so an unsafe fn prepare(…) should fit the purpose, isn't it?