Re: [c++-pthreads] Re: thread-safety definition
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [c++-pthreads] Re: thread-safety definition



> >This problem could be eliminated by specifying that cancellation
> >is a special case, that cannot be caught by catch(...), i.e., that
> >it can only be caught by a handler that names it explicitly, or that
> >it cannot be caught at all.
> 
> That was originally proposed, and it's a bad idea.  There's too much
> code of the form
>   catch(...) {
>     do_some_partial_cleanup();
>     throw;
>   }
> This is important, and it's recommended style.  Uncatchable
> exceptions would be a major change in the C++ exception model.

This existing code does not rely on being able to catch thread
cancellation, since it was written with only normal exceptions in
mind.  It is precisely because existing code does no know about
cancellation that we are having this dicussion, I thought.

The main point is that one does not want cancellation to be
caught by catch(...), *because* 
(1) we do not want it swallowed up;
(2) if we disable cancellation implicitly over destructors (and
    explicitly over other sections of code that should not
    propagate cancellation), we don't need to catch it

Making an exception to the sematics of exceptions for cancellation
is not a huge change.  Ada made this more palatable by defining
cancellation (task abort) to be a new thing, like an exception,
but different.  C++ has a chance to do this more elegantly, by
just adding a special-case rule for catch(...).

--Ted