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

Use less syscalls in anon_pipe() #39386

Merged
merged 2 commits into from
Feb 2, 2017
Merged

Conversation

tbu-
Copy link
Contributor

@tbu- tbu- commented Jan 29, 2017

Save a ENOSYS failure from pipe2 and don't try again.

Use cvt instead of cvt_r for pipe2 - EINTR is not an error
pipe2 can return.

Save a `ENOSYS` failure from `pipe2` and don't try again.

Use `cvt` instead of `cvt_r` for `pipe2` - `EINTR` is not an error
`pipe2` can return.
@rust-highfive
Copy link
Collaborator

r? @sfackler

(rust_highfive has picked a reviewer for you, use r? to override)

@@ -29,34 +30,33 @@ pub fn anon_pipe() -> io::Result<(AnonPipe, AnonPipe)> {
// CLOEXEC flag is to use the `pipe2` syscall on Linux. This was added in
// 2.6.27, however, and because we support 2.6.18 we must detect this
// support dynamically.
if cfg!(target_os = "linux") {
static TRY_PIPE2: AtomicBool = AtomicBool::new(cfg!(target_os = "linux"));
Copy link
Member

@nagisa nagisa Jan 29, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Preexisting:

pipe2 is also supported on freebsd (>= 10.0), netbsd (>= 6.0), dragonflybsd (appeared ~4.0-ish?), openbsd (>= 5.7). These probably should also appear in that cfg! above.

@alexcrichton
Copy link
Member

Looking back on this, I'm not actually sure why handling ENOSYS is here at all. We're not doing a syscall manually, but instead calling a glibc function. That means if it exists we won't get ENOSYS from what I understand. In that case can we just remove that branch?

@tbu-
Copy link
Contributor Author

tbu- commented Jan 30, 2017

True.

We're not calling the raw syscall but a libc function, the libc will
have a compatibility layer.
@tbu-
Copy link
Contributor Author

tbu- commented Jan 30, 2017

@alexcrichton Removed the branch.

@alexcrichton
Copy link
Member

@bors: r+

@bors
Copy link
Contributor

bors commented Jan 30, 2017

📌 Commit 4b46d2a has been approved by alexcrichton

@bors
Copy link
Contributor

bors commented Jan 31, 2017

⌛ Testing commit 4b46d2a with merge 1f7bafc...

@bors
Copy link
Contributor

bors commented Jan 31, 2017

💔 Test failed - status-travis

@alexcrichton
Copy link
Member

alexcrichton commented Jan 31, 2017 via email

@bors
Copy link
Contributor

bors commented Feb 1, 2017

⌛ Testing commit 4b46d2a with merge 3b88122...

@bors
Copy link
Contributor

bors commented Feb 1, 2017

💔 Test failed - status-appveyor

@tbu-
Copy link
Contributor Author

tbu- commented Feb 1, 2017

Some curl failed, looks unrelated.

@alexcrichton
Copy link
Member

alexcrichton commented Feb 1, 2017 via email

@bors
Copy link
Contributor

bors commented Feb 2, 2017

⌛ Testing commit 4b46d2a with merge d5f5474...

bors added a commit that referenced this pull request Feb 2, 2017
Use less syscalls in `anon_pipe()`

Save a `ENOSYS` failure from `pipe2` and don't try again.

Use `cvt` instead of `cvt_r` for `pipe2` - `EINTR` is not an error
`pipe2` can return.
@bors
Copy link
Contributor

bors commented Feb 2, 2017

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing d5f5474 to master...

@bors bors merged commit 4b46d2a into rust-lang:master Feb 2, 2017
@cuviper
Copy link
Member

cuviper commented Jun 8, 2017

Looking back on this, I'm not actually sure why handling ENOSYS is here at all. We're not doing a syscall manually, but instead calling a glibc function. That means if it exists we won't get ENOSYS from what I understand.

This is not necessarily true. Glibc has had the pipe2 symbol since 2.9, but it makes no effort to emulate the functionality if the kernel rejects it. The pipe2 stub does nothing, and the all of the arch-specific implementations are raw syscall wrappers that do nothing but copy returned errors to errno. So if your running kernel happens to be older, you'll just get ENOSYS. (I'll bet you can guess why I'm noticing this change now...)

@alexcrichton
Copy link
Member

Ack sorry about that @cuviper! The fix here would be to just reinstate ENOSYS handling to fall back to pipe, right?

@cuviper
Copy link
Member

cuviper commented Jun 8, 2017

Yeah, that should do it!

@alexcrichton
Copy link
Member

Ok I'll send a PR for this. Looks like this made it into 1.17.0 but we can at least backport and get it fixed for 1.19.0

@alexcrichton
Copy link
Member

#42521

alexcrichton added a commit to alexcrichton/rust that referenced this pull request Jun 8, 2017
Should help fix an accidental regression from rust-lang#39386.
frewsxcv added a commit to frewsxcv/rust that referenced this pull request Jun 8, 2017
std: Handle ENOSYS when calling `pipe2`

Should help fix an accidental regression from rust-lang#39386.
bors added a commit that referenced this pull request Jun 9, 2017
std: Handle ENOSYS when calling `pipe2`

Should help fix an accidental regression from #39386.
brson pushed a commit to brson/rust that referenced this pull request Jun 12, 2017
Should help fix an accidental regression from rust-lang#39386.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants