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

[Michael Kerrisk <mtk dot manpages at gmail dot com>]

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.

Cheers,

Michael