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

[David Abrahams]

Dave Butenhof <david.butenhof at hp.com> writes:

> David Abrahams wrote:
>
>>Dave Butenhof <david.butenhof at hp.com> writes:
>>  
>>
>>> There has to be ONE cancellation mechanism. It has to propagate and
>>> behave as an exception because there's a vast body of existing code
>>> in many languages that already provides cleanup mechanisms based on
>>> exceptions, and POSIX cancel cleanup can also be implemented as an
>>> exception.
>>>    
>>>
>>Yeah, but there's also a vast body of existing code that for practical
>>reasons has to assume that exceptions can't propagate across language
>>boundaries, and so has put other mechanisms in place to handle that
>>situation.
>>  
>>
> OK, I'll admit to being in the privileged elite -- my principle 
> development environment has been OpenVMS and Tru64 UNIX, both of which 
> had architected common exception environments from the start and C 
> compiler support to participate. This is especially true on OpenVMS 
> where basic operation of the system relies on exceptions. While Tru64 
> UNIX is more of a plain UNIX heritage, language and library developers 
> routinely exploited the exception library. C++ destructors have always 
> run when a POSIX exit or cancel *exception*, or an Ada or Java 
> exception, propagates; just because that's how it clearly ought to work, 
> it was easy to do, and why would anyone want to implement anything else? 
> Similarly, Ada finally clauses, and POSIX cleanup handlers, will fire on 
> propagation of a C++ exception. How could it not? Why would anyone not 
> want it to?

Sure, in an ideal world all languages' exception systems should
interoperate.

> This is the way it SHOULD work. The only way it CAN work in the long
> run. Unless you're planning to say "C++ is C++, and you can't mix it
> with anything else." (A very "UNIX" philosophy, perhaps; but one
> with which I strongly disagree...

Me too.  Why would I want to isolate C++ that way?  

> and I think also one that's highly impractical and unrealistic in
> our current universe.)

And becoming less realistic as the IA64 ABI propagates itself.
However, it does seem likely that interpreted languages such as Python
will not be able to easily achieve such smooth interoperability, even
where the ABI is adopted.

> In the long process of developing the IA64 ABI for UNIX98 (which
> unfortunately was abandoned for political reasons), I invested a lot
> of time in convincing not only the general ABI committee but also
> the C++ committee

?? I'm pretty sure I would have noticed any traffic from you in the
C++ committee reflectors on exceptions during that period.

> that exception-based cancel, on top of a common platform exception
> library shared by C, C++, Ada, Java, and anyone else, was an
> absolute basic necessity. I succeeded, incidentally, and a variant
> of an existing C++ exception package generalized to support a common
> cross-language exception model was proposed. It wouldn't have been a
> big deal for anyone with a C++ implementation to provide such a
> library.
>
> So, OK; I don't have a strong vested interest at this point in
> trying to build a decent C++ threading model. I've spent an enormous
> amount of time and energy doing that several times before; it's all
> been wasted, and I'm tired. I'm trying to provide some background
> and assistance to help you guys do it all yet again for the nth time
> without dropping the ball, but if you're going to go a different
> way, that's your business.  I'll just shut up and listen.

Whoa, dude; chill.  It's my impression that most of us are debating in
order to achieve clarity, not to try to force a particular decision.

BTW, I still haven't seen a clear statement of your position in the
scheme #1,2,3 contest.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com