pthread_cancel and EH: let's try this again

[Alexander Terekhov]

Peter Dimov wrote:
> 
> Alexander Terekhov wrote:
> > Wil Evers wrote:
> 
> >> * 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."
> 
> That's one of the few places where I think that we should not do what Posix
> says and just disable cancellation during unwinding instead. It has the same
> effect and solves the only real reported problem with the Tru64/OpenVMS
> model: that eating the cancellation exception leaves the thread running with
> cancelability disabled, causing the cancellation request to be lost without
> a trace.

It may partially[*] solve it in the case of dtors (making dtors have 
implicit throw()-nothing catch-less ES [ES fixed edition so to speak] 
by default and mandating intelligent cancel delivery would solve it 
much better and won't inhibit use of cancellation inside dtors), but
what about "unwinding" using catch-rethrow "dtors" that can also eat 
exceptions?

   try {
     operation();
   }
   catch(...) { 
     // End of stack unwinding
     try {
       cleanup();
     } 
     catch(...) { 
       // eat exception
     } 
     throw; // Begin of another stack unwinding
   }

http://www.boost.org/libs/smart_ptr/sp_techniques.html

"should be wrapped in a try {} catch(...) {} block that ignores exceptions"

http://lists.boost.org/MailArchives/boost/msg53471.php

I mean.

[*] Consider:

  struct X {

    X() {
      pthread_cancel(pthread_self());
    }

   ~X() throw() {
      printf("may go boom");
    }

  };

  int main() {
    X x;
  }

Where's no stack unwinding here. 

"The process of calling destructors for automatic objects constructed 
 on the path from a try block to a throw-expression is called 'stack 
 unwinding.'"

But with intelligent cancel delivery it won't go boom. And it would 
have zero overhead (no need to modify any flags) when you don't have
cancel requests pending. Many programs never call pthread_cancel()
and there is no reason (apart from misguided reluctance to mandate 
2-phase EH and fix ES) to penalize them.

regards,
alexander.