This is the mail archive of the
mailing list for the glibc project.
Re: [RFC][BZ #14627] Make linux close errno to EINPROGRESS when interrupted in signal.
- From: Rich Felker <dalias at aerifal dot cx>
- To: Russ Allbery <eagle at eyrie dot org>
- Cc: libc-alpha at sourceware dot org
- Date: Thu, 5 Dec 2013 18:29:13 -0500
- Subject: Re: [RFC][BZ #14627] Make linux close errno to EINPROGRESS when interrupted in signal.
- Authentication-results: sourceware.org; auth=none
- References: <20131205175749 dot GL24286 at brightrain dot aerifal dot cx> <20131205195802 dot GA19289 at lst dot de> <20131205201126 dot GO24286 at brightrain dot aerifal dot cx> <20131205 dot 155009 dot 707968344039994800 dot davem at davemloft dot net> <87ob4vggn3 dot fsf at windlord dot stanford dot edu> <20131205223223 dot GQ24286 at brightrain dot aerifal dot cx> <87zjoegbcf dot fsf at windlord dot stanford dot edu>
On Thu, Dec 05, 2013 at 02:52:00PM -0800, Russ Allbery wrote:
> Rich Felker <firstname.lastname@example.org> 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
> 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