Peter Dimov wrote:
It's certainly questionable whether a cleanup handler (TSD destructor) that explicitly enables cancellation and calls a cancellation point should re-cancel itself... and if it does, whether it should re-invoke itself, so it might be argued that this clarification introduced a new problem instead of fixing the old.
Scratch that, if this:"The cancelability state shall remain set to PTHREAD_CANCEL_DISABLE until the thread has terminated. The behavior is undefined if a cancellation cleanup handler or thread-specific data destructor routine changes the cancelability state to PTHREAD_CANCEL_ENABLE."
made it into the TC, it specifically prohibits the scenario I described. It also appears to prohibit enabling cancellation after catch(pthread_cancel_e) without rethrow, effectively disallowing catch without rethrow ("shall remain set to...").
int pthread_cancelenabled(void); RETURN VALUENonzero if the current thread's cancelability state is PTHREAD_CANCEL_ENABLE and the call is not made from within a cleanup handler or a TSD destructor, zero otherwise.
could have been much simpler.