-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Poll loop fixes #11624
Poll loop fixes #11624
Conversation
The event loop uses poll(2), not select(2).
- Check for errors. - Add O_NONBLOCK on top of any existing flags. set_nonblock() is adapted from lang_tester: https://github.com/softdevteam/lang_tester/blob/e01072a0a4c5e37f2e585c48efffcf540cd7b6a4/src/tester.rs#L1041-L1048
r? @ehuss (rustbot has picked a reviewer for you, use r? to override) |
What does this do/accomplish? How would we know if we break this functionality in the future? |
If one of your |
Also, getting the current flags and ORing in the non-block flag avoids destructively turning off any other flags the fd may already have set. |
Can you say what system you are running on and how you have been seeing it fail in cargo? Although I think this potentially looks more correct, I don't think anybody has reported any issues with the existing code in the past 6 years. So I'd like to better understand why we would be changing this. |
use std::io; | ||
use std::io::prelude::*; | ||
use std::mem; | ||
use std::os::unix::prelude::*; | ||
use std::process::{ChildStderr, ChildStdout}; | ||
|
||
fn set_nonblock(fd: c_int) -> io::Result<()> { | ||
let flags = unsafe { fcntl(fd, F_GETFL) }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is some uncertainty whether or not F_GETFL takes an argument. https://stackoverflow.com/questions/25061656/when-is-the-arg-for-f-getfl-fcntl-command-required has an interesting discussion of the issue. The Open Group specification notes that the arg value is reserved for future growth, without specifying what that means or what it should be set to or whether or not it should be specified. FreeBSD specifically says it is ignored. Very strange.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On OpenBSD and Linux the manual also says the argument is ignored.
To be clear. I've seen But regardless, it's good practice to check for errors defensively so that if there is a problem, it happens as close to the cause as possible. |
We good to go? |
ping? |
Thanks! I'll go ahead and merge. I'm a little uncomfortable with this change, but other than the uncertainty about F_GETFL's behavior, I don't know of any specific issues. I also generally avoid changing things if they aren't causing any issues. @bors r+ |
☀️ Test successful - checks-actions |
Update cargo 11 commits in 4a3c588b1f0a8e2dc8dd8789dbf3b6a71b02ed49..15d090969743630bff549a1b068bcaa8174e5ee3 2023-03-14 14:05:36 +0000 to 2023-03-21 17:54:28 +0000 - docs(contrib): Move higher level resolver docs into doc comments (rust-lang/cargo#11870) - docs(contrib): Pull impl info out of architecture (rust-lang/cargo#11869) - Update curl-sys (rust-lang/cargo#11871) - Poll loop fixes (rust-lang/cargo#11624) - clippy: warn `disallowed_methods` for `std::env::var` and friends (rust-lang/cargo#11828) - Add --ignore-rust-version flag to cargo install (rust-lang/cargo#11859) - Handle case mismatches when looking up env vars in the Config snapshot (rust-lang/cargo#11824) - align semantics of generated vcs ignore files (rust-lang/cargo#11855) - Add more information to wait-for-publish (rust-lang/cargo#11713) - docs: Address warnings (rust-lang/cargo#11856) - docs(contrib): Create a file overview in the nightly docs (rust-lang/cargo#11850)
Update cargo 11 commits in 4a3c588b1f0a8e2dc8dd8789dbf3b6a71b02ed49..15d090969743630bff549a1b068bcaa8174e5ee3 2023-03-14 14:05:36 +0000 to 2023-03-21 17:54:28 +0000 - docs(contrib): Move higher level resolver docs into doc comments (rust-lang/cargo#11870) - docs(contrib): Pull impl info out of architecture (rust-lang/cargo#11869) - Update curl-sys (rust-lang/cargo#11871) - Poll loop fixes (rust-lang/cargo#11624) - clippy: warn `disallowed_methods` for `std::env::var` and friends (rust-lang/cargo#11828) - Add --ignore-rust-version flag to cargo install (rust-lang/cargo#11859) - Handle case mismatches when looking up env vars in the Config snapshot (rust-lang/cargo#11824) - align semantics of generated vcs ignore files (rust-lang/cargo#11855) - Add more information to wait-for-publish (rust-lang/cargo#11713) - docs: Address warnings (rust-lang/cargo#11856) - docs(contrib): Create a file overview in the nightly docs (rust-lang/cargo#11850)
What does this PR try to resolve?
A couple of minor issues. See individual commits.
How should we test and review this PR?
The existing test suite should have sufficient coverage.
Additional information
(I have 5 apparently unrelated failures locally when running
cargo test
)