This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Mon, Dec 5, 2016 at 5:22 PM, Rich Felker <dalias@aerifal.cx> wrote:
> 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.

Yes, you got me. I went away and reread this in the time you wrote the
mail, and came to the same conclusion.

So, the summary looks like this, AFAICT. Current POSIX permits the
Linux behavior. Future POSIX proposes to make a change that
contradicts the behavior of at least three existing implementations
(Linux, FreeBSD, and AIX). That doesn't seem right. What have I
missed?

Cheers,

Michael


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]