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

Dave Butenhof david.butenhof at hp.com
Fri Jul 15 13:49:19 UTC 2005


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?

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... and I think also one that's highly 
impractical and unrealistic in our current universe.) 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 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: david.butenhof.vcf
Type: text/x-vcard
Size: 476 bytes
Desc: not available
URL: <http://sourcerytools.com/pipermail/c++-pthreads/attachments/20050715/cf5dacfb/attachment.vcf>


More information about the c++-pthreads mailing list