On Sat, 10 Jan 2004 22:19:41 +0100, Wil Evers <wil@xxxxxxxxxxxxxx> wrote:
Richard Henderson wrote:
On Fri, Jan 09, 2004 at 07:01:31AM +0100, Wil Evers wrote:
A second exception escaping from a destructor called while unwinding
the stack because of some earlier exception will result in program
termination.
If catching (and not rethrowing) this second exception breaks the
cancellation machinery, then it is the cancellation machinery - and not
the program in question - that is broken. In other words: we need a way
to prevent this scenario.
It would be trivial to adjust the c++ runtime to disable cancelation
while exceptions are in flight. That avoids that scenario entirely.
It obviously does. But does that imply we don't need
'catch-and-dont-rethrow' blocks in destructors anymore?
No, of course not; we can get double faults in non-threaded programs. It
does, however, mean that a cancellation exception will never be caught by
such a block.
[...]
I've noticed that some people on this list object to this design, but so
far, I haven't seen an alternative. In other words, I think we should be
prepared for threads that discard cancellation exceptions - which is why
Nathan's 'sticky cancellation' makes sense to me.
I agree that cancellation should be sticky, and it is in my model as well
as Nathan's. But I don't think that this particular example would discard
cancellation exceptions.