-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Optimize some functions in std::process #31618
Conversation
r? @brson (rust_highfive has picked a reviewer for you, use r? to override) |
db8d041
to
63ca1d9
Compare
☔ The latest upstream changes (presumably #31825) made this pull request unmergeable. Please resolve the merge conflicts. |
63ca1d9
to
2e9dbf1
Compare
☔ The latest upstream changes (presumably #31858) made this pull request unmergeable. Please resolve the merge conflicts. |
2e9dbf1
to
956de96
Compare
@bors r+ Glad to see that thread go. |
📌 Commit 956de96 has been approved by |
⌛ Testing commit 956de96 with merge 3365f3b... |
💔 Test failed - auto-win-msvc-64-opt |
956de96
to
b49d4b1
Compare
@bors: r=brson b49d4b1 |
⌛ Testing commit b49d4b1 with merge c2e412c... |
💔 Test failed - auto-win-msvc-64-opt |
b49d4b1
to
58e96a8
Compare
@bors: r=brson 58e96a8 |
⌛ Testing commit 58e96a8 with merge 4274c2a... |
@bors: retry force |
⌛ Testing commit 58e96a8 with merge 1b87ace... |
💔 Test failed - auto-linux-64-x-android-t |
58e96a8
to
3ff611f
Compare
@bors: r=brson 3ff611f |
⌛ Testing commit 3ff611f with merge 3e4519e... |
@bors: retry force |
⌛ Testing commit 7c3038f with merge 9fbff29... |
💔 Test failed - auto-mac-64-opt |
@bors: retry |
Optimize some functions in std::process * Be sure that `read_to_end` gets directed towards `read_to_end_uninitialized` for all handles * When spawning a child that guaranteed doesn't need a stdin, don't actually create a stdin pipe for that process, instead just redirect it to /dev/null * When calling `wait_with_output`, don't spawn threads to read out the pipes of the child. Instead drain all pipes on the calling thread and *then* wait on the process. Functionally, it is intended that nothing changes as part of this PR --- Note that this was the same as #31613, and even after that it turned out that fixing Windows was easier than I thought! To copy a comment from over there: > As some rationale for this as well, it's always bothered me that we've spawned threads in the standard library for this (seems a bit overkill), and I've also been curious lately as to our why our build times for Windows are so much higher than Unix (on the buildbots we have). I have done basically 0 investigation into why, but I figured it can't help to try to optimize Command::output which I believe is called quite a few times during the test suite.
😲 |
This regression was accidentally introduced in rust-lang#31618, and it's just flipping a boolean! Closes rust-lang#32254
…uron std: Fix inheriting stdin on status() This regression was accidentally introduced in rust-lang#31618, and it's just flipping a boolean! Closes rust-lang#32254
…uron std: Fix inheriting stdin on status() This regression was accidentally introduced in rust-lang#31618, and it's just flipping a boolean! Closes rust-lang#32254
This commit fixes a mistake introduced in rust-lang#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 rust-lang#38811
This commit fixes a mistake introduced in rust-lang#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 rust-lang#38811
std: Don't pass overlapped handles to processes 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
read_to_end
gets directed towardsread_to_end_uninitialized
for all handleswait_with_output
, don't spawn threads to read out the pipes of the child. Instead drain all pipes on the calling thread and then wait on the process.Functionally, it is intended that nothing changes as part of this PR
Note that this was the same as #31613, and even after that it turned out that fixing Windows was easier than I thought! To copy a comment from over there: