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

[Peter Dimov]

Alexander Terekhov wrote:

> 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
>   }

The stack unwinding doesn't end when the catch block is entered. That's when 
the exception is "caught" - uncaught_exception() starts returning true - but 
it's not until the catch block ends when the exception is considered 
"finished".

> [*] Consider:
>
>  struct X {
>
>    X() {
>      pthread_cancel(pthread_self());
>    }
>
>   ~X() throw() {
>      printf("may go boom");
>    }
>
>  };
>
>  int main() {
>    X x;
>  }

Yes, this can terminate() under most "non-intelligent" models, except the 
one where destructors disable cancellation. The cause of the termination is 
the throw() specification, though, not the destructor - you can replace ~X 
with an ordinary function. This is one of the motivating examples for the 
ECANCEL school of thought.