This is the mail archive of the 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 2/4] nptl: Handle EPIPE on tst-cancel2

On Tue, Sep 03, 2019 at 09:15:58AM -0300, Adhemerval Zanella wrote:
> On 02/09/2019 20:26, Rich Felker wrote:
> > If the descriptor has been closed, you *can't* act on cancellation. On
> > Linux, SYS_close *never* returns to userspace without the fd having
> > been closed. It can return EINTR, indicating that the fd has been
> > closed but the underlying open file description (if this was the last
> > reference to it) has not, but this EINTR is not POSIX conforming with
> > the new changes to POSIX, and it was always inconsistent with the
> > semantics implied by EINTR ("no nontrivial side effects have happened
> > yet"). See
> So is it true even for newer version? I had the impression from the lwn
> article [1] that this is driver dependent and this behaviour will eventually
> be removed from kernel to not allow close to return EINTR.
> About BZ#14627, does it still make sense for *Linux* to map EINTR to
> [1]

The kernel folks are adamantly opposed to changing SYS_close to match
the POSIX requirement here, which is the right thing to do but for the
wrong reasons -- if it were changed, libc could not safely handle the
situation because it couldn't know what meaning the kernel was
assigning to EINTR.

Hopefully they will just stop returning EINTR entirely. That would not
break any of the behavior discussed above. Returning EINPROGRESS may
be a problem though because applications may not know to expect it and
may treat it as a hard error rather than a reasonable condition
(discussed in
The ideal behavior is probably just returning 0.


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