Skip to content

many system calls don't handle EINTR #11214

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

Closed
thestinger opened this issue Dec 30, 2013 · 8 comments
Closed

many system calls don't handle EINTR #11214

thestinger opened this issue Dec 30, 2013 · 8 comments

Comments

@thestinger
Copy link
Contributor

POSIX system calls return with EINTR if a signal is sent to the process. Most uses of system calls need to be changed to looping until success. The fsync and fdatasync implementation in the native io::file need to do this too. A close call on non-Linux platforms also has to do this, but must not loop on Linux (thanks for nothing POSIX!).

@sfackler
Copy link
Member

Wouldn't SA_RESTART handle this? Or does that end up switched off somehow?

@alexcrichton
Copy link
Member

If you use libuv SA_RESTART is turned off, and arguably as a library these conditions should be handled regardless.

Note that I don't think that all syscalls can return EINTR, at least the man page I'm looking at doesn't have EINTR as an error for clock_gettime. This only really applies to blocking syscalls like read and write (which do handle EINTR right now), but this is not true for the general case (I had to fix it for waitpid recently).

Most things probably need to just get wrapped in this function: https://github.com/mozilla/rust/blob/master/src/libnative/io/mod.rs#L138

@thestinger
Copy link
Contributor Author

@alexcrichton: Yeah, clock_gettime was a bad example - I started this as a report that we weren't checking return values (CLOCK_MONOTONIC is optional) but then made it more specific.

@thestinger
Copy link
Contributor Author

It would save a lot of trouble if we used stdio instead and disabled buffering with setvbuf. :)

@brson
Copy link
Contributor

brson commented Dec 31, 2013

I remember reading recently that the situation with close failing is just hopeless on all unixes and a failing close should not be handled anywhere.

@thestinger
Copy link
Contributor Author

@brson: I think there are some operating systems where you're supposed to handle it but it doesn't appear we support any of them (HP-UX).

@mstewartgallus
Copy link
Contributor

What a coincidence! I was confused about the situation with close returning EINTR just a while ago. mac-reid was very helpful in giving me link 1 and link 2. I found they clarified the issue a lot.

bors added a commit that referenced this issue Jan 5, 2014
flip1995 pushed a commit to flip1995/rust that referenced this issue Jul 31, 2023
check that the types are equal in `SpanlessEq::eq_expr`

Fixes rust-lang#11213

changelog: [`if_same_then_else`]: don't lint for integer literals of different types
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 a pull request may close this issue.

6 participants