-
Notifications
You must be signed in to change notification settings - Fork 654
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
pipe2 doesn't set flags atomically? #414
Comments
I have no objection to this. Mind opening up a PR? |
I'd love to put it together, but I could use your advice about the right way to do it. Rust's libstd uses some kind of weak binding backed by function called |
Personally, at least for the first pass, I am OK only supporting linux 2.6.27+ in nix as long as we make a note that further work would be required to support older kernels. Alternatively, borrowing that macro/logic from libstd might also be an acceptable solution.
|
Interesting, it looks like musl already implements a similar fallback: http://git.musl-libc.org/cgit/musl/tree/src/unistd/pipe2.c |
call pipe2 directly on Linux A first shot at fixing #414. This approach keeps the old implementation for platforms other than `notbsd`, because `libc` only exposes `pipe2` in the `notbsd` module. I've tested this by hand on my Linux machine in a couple ways: - Create a toy program that opens a pipe and passes it to `cat`, which hags if `O_CLOEXEC` doesn't get set properly. Confirm that it doesn't hang, but that it does if I pass `0` as the flags to `libc::pipe2`. - Delete the new implementation entirely, and delete the `cfg` guards on the old implementation, and confirm that above is still true. I haven't actually tested a cross compilation build though. Is there a standard way to do that?
If I understand it, the situation cannot be improved, from where your PR got us. Can we close this now? |
Yep. Closing. Does |
It looks like the
pipe2
function is implemented as a call to regularpipe
followed by separate calls tofcntl
(for compatibility with systems that don't supportpipe2
?). I think that's fine for O_NONBLOCK, but not for O_CLOEXEC. If a multithreaded program forks in between the creation of a pipe and when O_CLOEXEC is set, the child will inherit pipes that it isn't supposed to.Is it possible to call the real
pipe2
libc function where it's supported, and to fall back topipe
only when necessary? I think this is what libstd does.The text was updated successfully, but these errors were encountered: