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 02/09/2019 13:37, Florian Weimer wrote:
> * Rich Felker:
>> No. POSIX is very clear that cancellation is only permitted to be
>> acted on when the side effects are the same as EINTR, which can only
>> happen for read/write when no data has been transferred yet. If data
>> has already been transferred, the only option not ruled out by one or
>> more constraints is to return successfully with a short read or write;
>> pending cancellation will then be handled on a subsequent call to a
>> cancellation point. (If you're doing a retry loop until the total
>> length n is transferred, then in the next iteration of the loop.)
> This seems to be a backwards interpretation to me.  I think POSIX wants
> to describe what can happen during cancellation, and not say that any
> cancellation point can be skipped if some side effect happens that
> cannot happen before EINTR.
>> Of course this case of non-conformance would be less severe than UAF
>> or resource leak errors in most cases, but it's still not good.
> Agreed.  And I think not acting on the cancellation and returning
> success is also not conforming.

how is that non-conformance observable?

the user cannot know if the cancellation
request arrived in time or not if io
error (short write) can happen for other
reasons than the cancellation signal.

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