[c++-pthreads] Re: pthread_cancel and EH: let's try this again

[Wil Evers]

Alexander Terekhov wrote:

>>* Cancellation is sticky: it causes an irreversible state change in the
>>target thread; subsequent cancellations have no further effect.
>  
> Stickiness can be achieved by the user code. By mandating stickiness,
> you don't really solve any problems. Note that mandated stickiness 
> would inhibit various useful things such as reuse of threads in a 
> thread pool executor without recycling after cancellation of a 
> "task"/"future" by means of thread cancellation.

Not sure about this one.  I can think of two ways of achieving 
stickiness through user code:

(*) Have the destructor of the cancellation exception re-cancel the 
current thread.  The problem with this is that the user has no real 
choice here - in your example, it would imply that the threads in the 
thread pool cannot be recycled.

(*) Have the user code re-cancel the current thread when a cancellation 
exception is caught and finalized.  The problem with this is that it 
requires the user to explicitly catch a cancellation exception by name. 
  It won't happen if the cancellation exception is finalized in a 'catch 
(...)' block; instead, the cancellation request will go unnoticed.

[snip]

>>* A thread's cancellation state is only affected by calls to
>>pthread_setcancelstate() originating from user code.
> 
> Intelligent cancel delivery aside for a moment, POSIX states:
> 
> "When a cancellation request is acted upon, or when a thread calls 
>  pthread_exit(), the thread first disables cancellation by setting 
>  its cancelability state to PTHREAD_CANCEL_DISABLE and its 
>  cancelability type to PTHREAD_CANCEL_DEFERRED."

Yes, this is incompatible with the rule I stated above.  Damn.

Not sure how serious it is, though.  Under the design I suggested, the 
first thing a thread's user code would do is disable cancellation, only 
to re-enable it for selected regions of code.

I would expect any exception finalization to take place *outside* of 
those regions; therefore, if the thread continues to run, cancellation 
will necessarily have been re-enabled before the user code hits another 
intended cancellation point.

So it seems that, for the sake of POSIX compatibility, the rule I stated 
above can be dropped without risking unintended suppression of 
cancellation requests.

- Wil