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

[Gabriel Dos Reis]

David Abrahams <dave at boost-consulting.com> writes:

| 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.  

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. 

-- Gaby