Skip to content
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

Spurious timeout in test net::tcp::tests::close_read_wakes_up #31657

Closed
pitdicker opened this issue Feb 14, 2016 · 2 comments
Closed

Spurious timeout in test net::tcp::tests::close_read_wakes_up #31657

pitdicker opened this issue Feb 14, 2016 · 2 comments
Labels
A-spurious Area: Spurious failures in builds (spuriously == for no apparent reason)

Comments

@pitdicker
Copy link
Contributor

It just happend with my unrelated pull request on auto-win-msvc-32-opt.
It is the only test that dit not complete between this build and the previous.
It also contains the comment: "this test will never finish if the child doesn't wake up"

@pitdicker
Copy link
Contributor Author

This seems to be relevant.
http://stackoverflow.com/questions/10935267/does-a-socket-shutdown-call-from-another-thread-always-make-blocking-recv-thre

A thread may not wake up on Windows if a socket is shut down.

@alexcrichton
Copy link
Member

Hm that just seems to indicate that the child will eventually wake up... I wonder if Shutdown::Both would fix the problem here?

@alexcrichton alexcrichton added the A-spurious Area: Spurious failures in builds (spuriously == for no apparent reason) label May 5, 2016
alexcrichton added a commit to alexcrichton/rust that referenced this issue Jan 6, 2017
It looks like in practice at least this test will not pass on Windows.
Empirically it is prone to blocking forever, presumably because a call to
`shutdown` doesn't actually wake up other threads on Windows.

We don't document this as a guarantee for `shutdown`, nor do we internally rely
on it. This test originated in a time long since passed when it was leveraged
for canceling I/O, but nowadays there's nothing fancy happening in the standard
library so it's not really a productive test anyway, hence just ignoring it on
Windows.

Closes rust-lang#31657
bors added a commit that referenced this issue Jan 12, 2017
std: Ignore close_read_wakes_up on Windows

It looks like in practice at least this test will not pass on Windows.
Empirically it is prone to blocking forever, presumably because a call to
`shutdown` doesn't actually wake up other threads on Windows.

We don't document this as a guarantee for `shutdown`, nor do we internally rely
on it. This test originated in a time long since passed when it was leveraged
for canceling I/O, but nowadays there's nothing fancy happening in the standard
library so it's not really a productive test anyway, hence just ignoring it on
Windows.

Closes #31657
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this issue Mar 8, 2022
…, r=Mark-Simulacrum

Enable `close_read_wakes_up` test on Windows

I wonder if we could/should try enabling this again? It was closed by rust-lang#38867 due to rust-lang#31657. I've tried running this test (along with other tests) on my machine a number of times and haven't seen this fail yet,

Caveat: the worst that can happen is this succeeds initially but then causes random hangs in CI. This is not a great failure mode and would be a reason not to do this.

If this does work out, closes rust-lang#39006

r? `@Mark-Simulacrum`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-spurious Area: Spurious failures in builds (spuriously == for no apparent reason)
Projects
None yet
Development

No branches or pull requests

3 participants