pthread_cancel and EH: let's try this again

[Alexander Terekhov]

Peter Dimov wrote:
[...]
> I don't insist on this particular model. I'm in favor of a family of models
> whose characteristic is no implicit cancel state manipulation and
> conditional cancel delivery.
> 
> The actual condition can be "no unfinished exception", but it can also be
> "no uncaught exception", "no unfinished cancellation exception", and so on.
                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

where the "finish" is manifested via enabling cancellation by the user
code.

> Whichever works best and is acceptable to implementors.
> 
> Simple heuristics such as "no unfinished exception" are obviously
> technically inferior to intelligent 2-phase query-based conditions with
> implicit throw() injections on destructors during unwinding, but they are
> much simpler to implement.

FYI, POSIX wording about explicit manipulation of cancel state and cancel 
type on part of the implementation when it delivers cancellation or acts 
upon pthread_exit() (cancel type is not an issue in this case) was added 
to POSIX by the recent TC in response to 

http://opengroup.org/austin/mailarchives/austin-group-l/msg05202.html 
http://opengroup.org/austin/mailarchives/austin-review-l/msg01449.html 
http://opengroup.org/austin/mailarchives/austin-review-l/msg01450.html 
http://opengroup.org/austin/mailarchives/austin-review-l/msg01451.html 

The driving force behind the DRs was a realization that being a mere C 
(99) extension, POSIX just can't mandated EH query machinery of 
expected_exception<>. I do still believe that in absence of 
expected_exception<> machinery, it was a pretty good approximation for
most (if not all) applications.

The C++ (threaded) extension can do better, of course... but it's too 
late to "undo" POSIX 2004 TC2 (if coexistence matters), I'm afraid.

regards,
alexander.