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

[Rich Felker <dalias at aerifal dot cx>]

On Mon, Dec 05, 2016 at 08:32:37AM -0800, Paul Eggert wrote:
> On 12/05/2016 08:22 AM, Rich Felker wrote:
> >POSIX-future does not permit the Linux behavior.
> 
> I'm not seeing where POSIX-future (i.e.,
> http://austingroupbugs.net/view.php?id=529 response 0001200 dated
> 2012-04-19 15:18) prohibits the GNU/Linux behavior.

See the following text:

------------------------------------------------------------------------
At line 22871 [XSH close DESCRIPTION], change:

If close( ) is interrupted by a signal that is to be caught, it shall
return -1 with errno set to [EINTR] and the state of fildes is
unspecified. If an I/O error occurred while reading from or writing
to the file system during close( ), it may return -1 with errno set to
[EIO]; if this error is returned, the state of fildes is unspecified.

to:

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.
------------------------------------------------------------------------

If close returns -1 with errno set to EINTR, filedes must remain open
(so that it is not subject to being re-assigned, in which case you
have dangerous double-close races when looping on EINTR).

> If there is such
> a prohibition, isn't that more likely to be a bug in POSIX-future
> than in GNU/Linux?

No. This whole issue has been discussed to death and the bug is in
Linux (not GNU/Linux, as it's in no way GNU's fault). Glibc is
hopefully going to fix it on the userspace side; I have an open bug
for it but it hasn't gotten a lot of attention:

https://sourceware.org/bugzilla/show_bug.cgi?id=14627

Rich