std.os: don't always retry close() on EINTR

[daurnimator]

At the moment, close is retried on EINTR.

zig/std/os.zig

Line 270 in f479829

posix.EINTR => continue,

On many operating systems, you shouldn't do this. e.g. From linux man page:

In particular close() should not be retried after an EINTR since this may cause a reused descriptor from another thread to be closed.

If my earlier research is correct:

• HP-UX you try again
• Linux, Solaris and AIX you don't want to retry again
• OSX is ill-defined and hence unsafe, you should use close_nocancel instead and not try again.

Related links:

• http://austingroupbugs.net/view.php?id=529
• http://alobbs.com/post/54503240599/close-and-eintr
• http://www.daemonology.net/blog/2011-12-17-POSIX-close-is-broken.html
• https://code.google.com/p/chromium/issues/detail?id=269623
• Handle EINTR when closing sockets wahern/cqueues#56

[bnoordhuis]

OSX is ill-defined and hence unsafe, you should use close_nocancel instead and not try again.

FWIW, I was curious if this is still an issue with recent xnu kernels and it is: close() returns EINTR when a thread cancellation request is pending but without closing the file descriptor.

It seems like a rather bizarre deviation from the POSIX spec. I have no idea why xnu works like that. Legacy, perhaps?

FWIW, glibc's close() wrapper has a similar issue - it unwinds the thread when a cancellation is pending - but at least that's according to spec. Still a file descriptor leak, though.

Musl's close() isn't a cancellation point and isn't affected.

[daurnimator]

It seems like a rather bizarre deviation from the POSIX spec. I have no idea why xnu works like that. Legacy, perhaps?

POSIX leaves it undefined; as each POSIX OS does it differently 😲 (see my austingroup link)

[bnoordhuis]

Sorry, reading back what I wrote I realize it's not clear I was talking about thread cancellation itself, not whether it leaves the file descriptor open or not.

close() is a cancellation point with well-defined semantics but xnu doesn't follow the spec. EINTR is allowed when the thread is cancelled while suspended inside the close() system call but xnu returns EINTR upon entering the system call.

The expected behavior is that it terminates the thread but AFAICT, that never happens on xnu and hence close() is effectively not a cancellation point.

If you had something like pthread_cancel(pthread_self()); RETRY_ON_EINTR(close(fd)); in your code, it looks like it could loop forever.

(That said, it's probably largely academic because no one uses thread cancellation. At least, I've never seen a program that does.)