pthread_cancel and EH: let's try this again
David Abrahams
dave at boost-consulting.com
Wed Jul 13 17:58:56 UTC 2005
Dave Butenhof <david.butenhof at hp.com> writes:
> There are many complicated compatibility issues in modelling something
> like POSIX cancellation in C++ without breaking some usage patterns of
> C++ exceptions. There's no way around that. In particular, arguments of
> "it has to be this way because" or "it can't be this way because" miss
> the point. Or rather, if you're going to insist that IS the point then
> it just can't be done and we should face that any C++ code using cancel
> is inherently broken. Otherwise, existing usage patterns are going to
> change, and a lot of code will be adversely impacted by the changes;
> either to traditional C++ exception usage patterns or to traditional
> POSIX cancellation usage patterns.
Agree. However, I think it's a good idea to think about which usage
patterns would be disrupted, and by how much, and how harmful that
disruption turns out to be.
So far, it looks to me as though #1 does a lot less harm than #2. In
particular, I'm not much disturbed if in the example Jason posted the
author of the outer catch(...) block has to add a
catch(cancellation&) { return; }
That's a nicely localized sort of change.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
More information about the c++-pthreads
mailing list