rust/src/libstd/sys/windows/process.rs, branch 1.26.0

Deprecate the AsciiExt trait in favor of inherent methods

2018-03-21T16:54:33+00:00

The trait and some of its methods are stable and will remain. Some of the newer methods are unstable and can be removed later. Fixes https://github.com/rust-lang/rust/issues/39658

Move process::ExitCode internals to sys

2018-03-04T02:44:44+00:00

Now begins the saga of fixing compilation errors on other platforms...

Capture environment at spawn

2017-12-24T14:24:31+00:00

Remove import of now unused AsciiExt

2017-11-04T18:16:03+00:00

I also replaced a wildcard import with a specific one, while I was at it.

Add conversions from File and Child* handles to Stdio

2017-06-06T22:42:55+00:00

`Stdio` now implements `From`, `From`, `From`, and `From`. The `Command::stdin`/`stdout`/`stderr` methods now take any type that implements `Into`. This makes it much easier to write shell-like command chains, piping to one another and redirecting to and from files. Otherwise one would need to use the unsafe and OS-specific `from_raw_fd` or `from_raw_handle`.

Always quote program name in Command::spawn on Windows

2017-06-04T20:47:24+00:00

`CreateProcess` will interpret args as part of the binary name if it doesn't find the binary using just the unquoted name. For example if `foo.exe` doesn't exist, `Command::new("foo").arg("bar").spawn()` will try to launch `foo bar.exe` which is clearly not desired.

std: Don't cache stdio handles on Windows

2017-03-23T14:22:48+00:00

This alters the stdio code on Windows to always call `GetStdHandle` whenever the stdio read/write functions are called as this allows us to track changes to the value over time (such as if a process calls `SetStdHandle` while it's running). Closes #40490

make Child::try_wait return io::Result>

2017-02-07T04:04:47+00:00

This is much nicer for callers who want to short-circuit real I/O errors with `?`, because they can write this if let Some(status) = foo.try_wait()? { ... } else { ... } instead of this match foo.try_wait() { Ok(status) => { ... } Err(err) if err.kind() == io::ErrorKind::WouldBlock => { ... } Err(err) => return Err(err), } The original design of `try_wait` was patterned after the `Read` and `Write` traits, which support both blocking and non-blocking implementations in a single API. But since `try_wait` is never blocking, it makes sense to optimize for the non-blocking case. Tracking issue: https://github.com/rust-lang/rust/issues/38903

Auto merge of #38866 - alexcrichton:try-wait, r=aturon

2017-01-09T07:01:10+00:00

std: Add a nonblocking `Child::try_wait` method This commit adds a new method to the `Child` type in the `std::process` module called `try_wait`. This method is the same as `wait` except that it will not block the calling thread and instead only attempt to collect the exit status. On Unix this means that we call `waitpid` with the `WNOHANG` flag and on Windows it just means that we pass a 0 timeout to `WaitForSingleObject`. Currently it's possible to build this method out of tree, but it's unfortunately tricky to do so. Specifically on Unix you essentially lose ownership of the pid for the process once a call to `waitpid` has succeeded. Although `Child` tracks this state internally to be resilient to multiple calls to `wait` or a `kill` after a successful wait, if the child is waited on externally then the state inside of `Child` is not updated. This means that external implementations of this method must be extra careful to essentially not use a `Child`'s methods after a call to `waitpid` has succeeded (even in a nonblocking fashion). By adding this functionality to the standard library it should help canonicalize these external implementations and ensure they can continue to robustly reuse the `Child` type from the standard library without worrying about pid ownership.

std: Add a nonblocking `Child::try_wait` method

2017-01-07T05:20:39+00:00

This commit adds a new method to the `Child` type in the `std::process` module called `try_wait`. This method is the same as `wait` except that it will not block the calling thread and instead only attempt to collect the exit status. On Unix this means that we call `waitpid` with the `WNOHANG` flag and on Windows it just means that we pass a 0 timeout to `WaitForSingleObject`. Currently it's possible to build this method out of tree, but it's unfortunately tricky to do so. Specifically on Unix you essentially lose ownership of the pid for the process once a call to `waitpid` has succeeded. Although `Child` tracks this state internally to be resilient to multiple calls to `wait` or a `kill` after a successful wait, if the child is waited on externally then the state inside of `Child` is not updated. This means that external implementations of this method must be extra careful to essentially not use a `Child`'s methods after a call to `waitpid` has succeeded (even in a nonblocking fashion). By adding this functionality to the standard library it should help canonicalize these external implementations and ensure they can continue to robustly reuse the `Child` type from the standard library without worrying about pid ownership.