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

[Rich Felker <dalias at aerifal dot cx>]

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.

Rich