catch(...) and forced unwind

[David Abrahams]

Mark Mitchell <mark@codesourcery.com> writes:

> (3) The thread_cancellation objects contain a reference count; copying
> the object increments the reference count and destroying the object
> decrements the reference count.  If the reference count goes to zero (as
> would happen when the exception is caught and not rethrown) the thread
> is uncancelled.

If "uncancelled" doesn't mean "re-deferred", I don't see the point of
the reference count.  How is the "uncancelled" case different from
the one where a copy of the thread_cancellation object is kept alive
indefinitely, i.e.

  catch (posix::thread_cancellation& x)
  { 
     some_stack.push(new (nothrow) thread_cancellation(x));
  }

?

> With these changes, library designers can still say "catch all
> exceptions", but they can also say "catch all exceptions except thread
> cancellation".  

How?  You must mean something like:

  try { ... }
  catch (posix::thread_cancellation&) { throw; }
  catch (...) {
        ... // here
  }

That's still catching thread cancellation, so I would choose a
different description if that's what you meant.

> It may be that catching all exceptions is a bad idea,
> but that is up to the library designer.
>
> These changes are a pure extension to POSIX threads; they do not break
> any existing POSIX threads code.  
>
> These changes are not quite a pure extension to standard C++; the C++
> standard prohibits C library functions from throwing exceptions, so, for
> example, "printf" cannot throw an exception.  

I'm not convinced there's a better solution, but it seems to me that
this could be a disaster for the ability to freely use C++ libraries
in threads without knowing something about their implementations.

Is it worth considering adding a mechanism which turns off
cancellation exceptions during unwinding?  I realize it's a
half-measure, but at least it would prevent some printf logging code
from sending us to terminate.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com