pthread_cancel and EH: let's try this again

[Alexander Terekhov]

Wil Evers wrote:
> 
> Nathan Myers wrote:
> 
> > I hate to contradict Mark, but I think we've made real progress this
> > time around (unlike last).  Pace Wil's pessimism, he has proposed
> > a workable design, compatible with standard C++ semantics and the
> > needs of thread coders alike.
> 
> However, I believe my suggestion does imply certain requirements on the
> threads library.  Perhaps it's time to list these, so here's model #5
> (Is it really 5?  I think so.)
> 
> * Threads are created with cancellation enabled (this is just repeating
> what POSIX says, I think).

Yes.

> 
> * 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.

> 
> * A cancellation exception is a normal C++ exception.  In particular, it
> can be caught by a catch (...), and there is no requirement that it must
> be rethrown if caught.

Yes.

> 
> * 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."

regards,
alexander.