[c++-pthreads] What are the real issues?

[Ted Baker]

> > From what I've read here, and my own experience, it seems this is
> > the right thing to do, provided:
> > 
> > 1) The only way to handle this new cancellation exception is via a
> > new syntax.

> Unfortunately that would conflict with standard C++ semantics, which
> say that any exception can be caught and handled using the catch-elipsis
> construct "catch (...)".

Ada says the same thing about real exceptions.
The difference is that abort is defined separately,
semantically analogous enough to exceptions that you can
implement it using the same mechanism, but distinct enough
that it cannot be caught by an exception handler.

The handlers to catch abort are a GNAT-specific extension, which
we implementors of language runtime support libraries found it
very helpful.

The only form of cleanup *users* have for task abort
are object finalizers.

I think this is still seems closest to the C++ philosophy I've
seen expressed by several people on this list, i.e., that the
right C++ way to provide clean thread cancellation is to use local
objects with finalizers (destructors) that do the cleanup.

Of course, a finalizer/destructor could go into an infinite 
loop, recursion, or in some other way indefinitely postpone
cancellation, but that is less likely than if one can
provide arbitrary handlers.  That is, a person who writes
a destructor normally understands that it is supposed to do
just a little work, and then return.  A person who writes
an exception handler is likely to use it to continue a
computation, e.g., a handler inside a loop body, that
allows the loop to go on to the next iteration.

--Ted Baker