about summary refs log tree commit diff
path: root/src/rustllvm/RustWrapper.cpp
diff options
context:
space:
mode:
authorbors <bors@rust-lang.org>2017-01-06 23:49:57 +0000
committerbors <bors@rust-lang.org>2017-01-06 23:49:57 +0000
commit7e38a89a7b970181be083691504825a23e6b0a0f (patch)
tree68cbc73d98cba21932fd3ed19d73205811f7d6ea /src/rustllvm/RustWrapper.cpp
parent373efe8794defedc8ce41e258910560423d0c0b7 (diff)
parent5148918db606689abea8f971ceb6c5bec4c0ba52 (diff)
downloadrust-7e38a89a7b970181be083691504825a23e6b0a0f.tar.gz
rust-7e38a89a7b970181be083691504825a23e6b0a0f.zip
Auto merge of #38835 - alexcrichton:less-overlapped, r=brson
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
Diffstat (limited to 'src/rustllvm/RustWrapper.cpp')
0 files changed, 0 insertions, 0 deletions