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

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.

std: Don't pass overlapped handles to processes

2017-01-04T23:37:12+00:00

This commit fixes a mistake introduced in #31618 where overlapped handles were leaked to child processes on Windows. On Windows once a handle is in overlapped mode it should always have I/O executed with an instance of `OVERLAPPED`. Most child processes, however, are not prepared to have their stdio handles in overlapped mode as they don't use `OVERLAPPED` on reads/writes to the handle. Now we haven't had any odd behavior in Rust up to this point, and the original bug was introduced almost a year ago. I believe this is because it turns out that if you *don't* pass an `OVERLAPPED` then the system will [supply one for you][link]. In this case everything will go awry if you concurrently operate on the handle. In Rust, however, the stdio handles are always locked, and there's no way to not use them unlocked in libstd. Due to that change we've always had synchronized access to these handles, which means that Rust programs typically "just work". Conversely, though, this commit fixes the test case included, which exhibits behavior that other programs Rust spawns may attempt to execute. Namely, the stdio handles may be concurrently used and having them in overlapped mode wreaks havoc. [link]: https://blogs.msdn.microsoft.com/oldnewthing/20121012-00/?p=6343 Closes #38811

just add one method named creation_flags, fix the tidy error

2016-12-01T02:31:47+00:00

Add std::os::windows::process::CommandExt, with set_creation_flags and add_creation_flags methods. Fixes #37827

2016-12-01T00:44:07+00:00

This adds a CommandExt trait for Windows along with an implementation of it for std::process::Command with methods to set the process creation flags that are passed to CreateProcess.

Use `#[prelude_import]` in `libstd`.

2016-08-24T22:12:48+00:00