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/
