Re: [PATCH] Manual should discourage mixing TEMP_FAILURE_RETRY and close

[Rich Felker <dalias at aerifal dot cx>]

On Mon, Dec 05, 2016 at 05:18:28PM +0100, Michael Kerrisk wrote:
> Hi,
> 
> On Mon, Dec 5, 2016 at 5:11 PM, Rich Felker <dalias@aerifal.cx> wrote:
> > On Mon, Dec 05, 2016 at 03:48:56PM +0100, Michael Kerrisk wrote:
> >> For what it's worth, well after the fact...
> >>
> >> On Wed, Dec 4, 2013 at 1:08 AM, Ondřej Bílka <neleai@seznam.cz> wrote:
> >> > On Tue, Dec 03, 2013 at 01:05:21PM -0500, Mark Mentovai wrote:
> >> >> When the close system call is interrupted by a signal, the state of its
> >> >> file descriptor argument is not specified[1]. On Linux, a close that
> >> >> fails with EINTR must not be restarted because the file descriptor is
> >> >> guaranteed to have been closed at that point[2]. Note that the kernel
> >> >> itself never restarts a close when SA_RESTART is set or when no
> >> >> user-space signal handler is present[3].
> >> >>
> >> > This is linux problem, POSIX now says
> >> >
> >> > http://austingroupbugs.net/view.php?id=529
> >> >
> >> > If close( ) is interrupted by a signal that is to be caught, then it
> >> > is unspecified whether it returns -1 with errno set to [EINTR] with
> >> > fildes remaining open, or returns -1 with errno set to [EINPROGRESS]
> >> > with fildes being closed, or returns 0 to indicate successful
> >> > completion; except that if POSIX_CLOSE_RESTART is defined as 0, then
> >> > the option of returning -1 with errno set to [EINTR] and fildes
> >> > remaining open shall not occur. If close() returns -1 with errno set
> >> > to [EINTR], it is unspecified whether fildes can subsequently be
> >> > passed to any function except close( ) or posix_close( ) without error..
> >> > For all other error situations (except for [EBADF] where fildes was
> >> > invalid), fildes shall be closed. If fildes was closed even though
> >> > the close operation is incomplete, the close operation shall continue
> >> > asynchronously and the process shall have no further ability to track
> >> > the completion or final status of the close operation.
> >>
> >> Yes, but POSIX never said that. That was a proposal that was
> >> discussed, that subsequently got shot down...
> >
> > It was not shot down. It was accepted for inclusion in the next issue
> > of POSIX. 2016 is not a new issue; it's a TC for POSIX-2008, and
> > cannot include non-bugfix changes.
> 
> You're right. I misread the order of entries in bug (was looking at an
> older proposal that was shot down), and mismatched with what Ondrej
> quoted.
> 
> But the point is still the same. Current POSIX.1 permits the Linux
> behavior, and future POSIX will too. So, the glibc manual still should
> get Mark's fix, I'd say.

No, POSIX-future does not permit the Linux behavior. If EINTR is
returned, the fd must still be "open" (not re-assignable, compatible
with calling close on it again, though it may be in a partially-closed
and unusable state). If the fd has been deallocated such that it's not
safe to call close on it again, close must return some value other
than EINTR; EINPROGRESS is added as the canonical error for the case
where closing is not complete and happens in the background.

Rich