many system calls don't handle EINTR

[thestinger]

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]

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

[alexcrichton]

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]

@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]

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

[brson]

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]

@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]

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.

[octurion]

@brson: SQLite does exactly that: http://repo.or.cz/w/sqlite.git/blob/7e210f7763816bf68dd111e3017465a84690ff99:/src/os_unix.c#l1169