Re: [c++-pthreads] Re: FW: RE: Re: I'm Lost
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [c++-pthreads] Re: FW: RE: Re: I'm Lost



David Abrahams wrote:

> If "finalized cancellation exceptions result in a new throw at the
> next cancellation point" isn't enough of a compromise, it isn't going
> to be me either, because I'm out of new ideas.

That sounds fine to me.  The key invariant that I feel must be preserved
is that cancellation is an exception, with all that implies.  (Actually
I'd made one exception to that requirement: if people wanted to say that
the type of the exception is unnameable, and that you cannot therefore
catch it by any means other than ..., I would see that as an
unnecessary, but acceptable, restriction.)

Your suggestion is to make functions which already throw exceptions (in
this context) throw them more often, which is OK; callers have to be
prepared for them to throw exceptions anyhow.  (You do have to say what
happens if the thread is cancelled, catches the exceptions, sets the
no-cancel bit, and then reaches a cancellation point.  The answer must
be that the thread is not cancelled, since, in that context, the
surrounding code can reasonably be written to assume there will no
exceptions.)

As far as I can tell, the last time we discussed this issue, all of the
C++ experts agreed that not allowing cancellation exceptions to be
caught was a serious violation of C++ exception-safety principles.

The key obstacle to progress here, AFAICT, is that Ulrich Drepper has
claimed that once cancellation occurs it is (in some unexplained way)
impossible for the thread to continue, despite the fact that it can run
its cancellation handlers, etc.  I've never been able to tell if he
thinks this to be a POSIX requirement, a Linux kernel issue, a GLIBC
implementation issue, or something else.

-- 
Mark Mitchell
CodeSourcery
mark@xxxxxxxxxxxxxxxx
(650) 331-3385 x713