Bug#1008174: libc6: poll() spuriously returns EINTR
Hi,
Le lauantaina 26. maaliskuuta 2022, 21.34.38 EET Aurelien Jarno a écrit :
> > As far as I understand, POSIX allows (or even requires) thread
> > cancellation to be essentially like a signal interruption, save for
> > ending the thread. But that is *only* from the moment that cancellation
> > is effected. Cancellation cannot be effected while it is disabled by
> > definition, so the behaviour from glibc seems wrong here.
>
> poll() is a cancellation point. It appears to me that POSIX actually
> allows this behaviour for cancellation points:
I don't think so...
> "The side effects of acting upon a cancellation request while suspended
> during a call of a function are the same as the side effects that may be
> seen in a single-threaded program when a call to a function is
> interrupted by a signal and the given function returns [EINTR]. Any such
> side effects occur before any cancellation cleanup handlers are called."
AFAIU, in POSIX, "acting upon" a cancellation request means to move the
cancellation request past the pending state, in other words, actually cancel
the thread. That quote clarifies that the signal-like interruption is observed
in the cancelled thread flow of execution before the cancellation clean-up
handlers.
Otherwise the next paragraph would not make much sense, particularly the last
sentence:
> "Whenever a thread has cancelability enabled and a cancellation request has
> been made with that thread as the target, and the thread then calls any
> function that is a cancellation point (such as pthread_testcancel() or
> read()), the cancellation request shall be acted upon before the function
> returns. If a thread has cancelability enabled and a cancellation request is
> made with the thread as a target while the thread is suspended at a
> cancellation point, the thread shall be awakened and the cancellation
> request shall be acted upon."
> "However, if the thread is suspended at a cancellation point and the event
> for which it is waiting occurs before the cancellation request is acted
> upon, it is unspecified whether the cancellation request is acted upon or
> whether the cancellation request remains pending and the thread resumes
> normal execution."
And it would get even more nonsensical / contradictory in the following
section:
> "When a cancellation request is acted upon, (...) the thread first disables
> cancellation by setting its cancelability state to PTHREAD_CANCEL_DISABLE
> and its cancelability type to PTHREAD_CANCEL_DEFERRED. The cancelability
> state shall remain set to PTHREAD_CANCEL_DISABLE until the thread has
> terminated."
This paragraph clarifies that cancellation cannot occur recursively / more than
once per thread.
Assuming that "acting upon a cancellation request" would be permissible with
cancellation disabled, this sentence would imply that cancellation is disabled
permanently, and the thread will never get cancelled at all.
--
Rémi Denis-Courmont
http://www.remlab.net/
Reply to: