Re: [RFC][BZ #14627] Make linux close errno to EINPROGRESS when interrupted in signal.

[Rich Felker <dalias at aerifal dot cx>]

On Thu, Dec 05, 2013 at 02:52:00PM -0800, Russ Allbery wrote:
> Rich Felker <dalias@aerifal.cx> writes:
> 
> > You missed the beginning of this discussion (which, to be fair, was in
> > another thread:
> > https://www.sourceware.org/ml/libc-alpha/2013-12/msg00108.html) where it
> > was noted that POSIX has fixed this bug:
> 
> > http://austingroupbugs.net/view.php?id=529
> 
> > The new requirement is that EINTR means the fd is still open and
> > EINPROGRESS means the operation was interrupted by a signal but the fd
> > is no longer valid.
> 
> Ah, thank you, I did.
> 
> However, that does imply that all C programmers should, to avoid file
> descriptor leaks on conforming POSIX systems, check the return status of
> close() and retry (some number of times?) if close fails with EINTR.
> 
> I'm pretty sure that almost no one does that in real code.

The reason nobody does it is that Linux (and perhaps a few other
systems) have historically behaved differently, and given the choice
between a rare fd leak or a rare double-close (which can cause MASSIVE
damage in a multi-threaded program), sane programmers generally choose
the former.

> I suppose what I'm saying is that I'm in agreement with you that returning
> 0 is probably the best approach, since it's not at all clear what we gain
> from returning -1 with EINPROGRESS and I doubt code deals with it
> correctly anyway.  (It's not even clear to me what "correctly" would
> entail in that case.)  That said, between the other choices, the
> EINPROGRESS approach which declares the file descriptor closed strikes me
> as clearly better than the POSIX EINTR semantics (which sound like they're
> not even possible on Linux).

The POSIX EINTR semantics are not possible on Linux. Once the fd is
closed, the same fd number could be assigned immediately to another
thread, in which case there's not even the option to _emulate_ the
POSIX EINTR behavior by re-opening a dummy file on the old fd number.
Anyway POSIX does not require EINTR to be able to happen; it just
requires that, if it does happen, the fd is still valid to re-pass to
close. Returning EINPROGRESS or even 0 instrad of EINTR is perfectly
acceptable. EINPROGRESS is what POSIX would encourage, but 0 is valid
since the case of getting interrupted by a signal _during_ close is
indistinguishable from the case of having the signal occur just after
close returns (successfully with 0) but before the caller uses the
return value.

Rich