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

[Jason Merrill]

On 14 Jul 2005 03:14:05 +0200, Gabriel Dos Reis <gdr at integrable-solutions.net> wrote:

> Jason Merrill <jason at redhat.com> writes:
>
> | On 13 Jul 2005 21:52:14 +0200, Gabriel Dos Reis <gdr at integrable-solutions.net> wrote:
> | 
> | > I think cancellation should be left as ordinary C++, catchable through
> | > catch(...).  I don't think we should second guess client code and
> | > design a new model of exception. 
> | 
> | My point is that making it an exception is also second-guessing client
> | code which is written to use the POSIX C binding.
>
> Even when it has been made clear that POSIX cancellation has always
> been thought and conceived as exceptions?  

Yes.  If there had been a POSIX C++ binding years ago, based on the Tru64
model, it could have used exceptions.  If we somehow managed to throw
together a C++ binding this year, it probably could still use exceptions.
But I don't think that's likely to happen, and in its absence the C binding
is the de facto C++ binding, and I think we need to support it.

I should state that more strongly: I would be very much in favor of a POSIX
C++ binding that made cancellation an exception.  But we need it last year,
and as far as I know there isn't even a subcommittee working on it; this
mailing list doesn't have any formal standing.

> I understand the issue is tough, but I don't see much gain in having
> another exception model with subtly different semantics.

It's not that subtle, it just does stack unwinding, like a sequence of
returns.

> It is true that many codes have been written with POSIX C binding, more
> has to come as C++ codes.  I'm not convinced that we should compromise
> the future.

The future can use a different interface.  Or extend pthread_setcanceltype.
PTHREAD_CANCEL_DEFERRED_EXCEPTION, anyone?

Jason