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

[Dave Butenhof]

David Abrahams wrote:

>Dave Butenhof <david.butenhof at hp.com> writes:
>  
>
>>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.
>>    
>>
>Sure, in an ideal world all languages' exception systems should
>interoperate.
>  
>
The problem here for me is that so many consider this a "nice but 
unrealistic" goal; but it's something I've relied on and taken for 
granted for most of my professional career on OpenVMS and Tru64 UNIX. 
There's nothing unrealistic. And if you can implement a C++ exception 
runtime, you can implement and deploy a language-independent exception 
runtime everyone can share. This isn't rocket science -- just basic 
computer science.

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

>>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.
>  
>
Java does. Of course it's 'semi-compiled'. So is Perl, and perhaps 
Python although I know little about Python. (The last whitespace 
dependent language I tried to learn was RPG-II [OK, that's an extreme 
example], and I can't dredge up any interest in dealing with another. ;-) )

>>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.
>  
>
I don't recall much email discussion on the ABI working groups -- this 
was almost exclusively teleconferences, and the status and reports 
weren't on any established C++ email list.

>>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.
>  
>
OK, so I'm being overdramatic. Comes from living with 2 daughters who 
are into acting, I suppose. Still, it's frustrating to have the same 
issues crop up over and again. And, yeah, part of the point was 
precisely that I really can chill -- this isn't my job or my problem, 
and I can cut back and sit it out rather than drive myself crazy arguing 
the same stuff over again. And I'm about to chill (despite the heat and 
humidity here in New England) because tomorrow I leave for a week on a 
quiet island in Lake Winnipesauke with no internet.

>BTW, I still haven't seen a clear statement of your position in the
>scheme #1,2,3 contest.
>  
>
My goals are along different lines.

   1. POSIX cancel and exit, C++ exceptions, Ada exceptions, and so
      forth, are all implemented under a common unified runtime model.
   2. Propagation of any of these "structured unwinds" (by whatever name
      and purpose) will run appropriate language-specified cleanup,
      including POSIX cleanup handlers, C++ destructors, Ada finally
      clauses, and so forth; no matter how various language frames may
      be interleaved.

Although I have personal preferences, I really don't care that much 
whether C++ allows catching cancel/exit with catch(...), whether a 
re-raise is forced or discretionary, whether it has a class name that 
can be caught explicitly.

MY involvement is not as an expert in C++ language (standards or common 
usage); but as a casual C++ user with a lot of experience in threads and 
with several comprehensive exception models that have worked in 
practice. There are many corners into which C++ is trapped by existing 
standards and practices. (Some for perfectly good reasons, but it really 
doesn't matter now since nobody's going to tear the language apart and 
start over.)

To put it another way, MY points 1 and 2 affect the ability to correctly 
and cleanly integrate POSIX threads and C++. The distinctions between 
schemes 1, 2, and 3 outlined in this discussion thread are "internal C++ 
politics". I don't consider any of them IDEAL, nor do I think does 
anyone else. The world will muddle through with any of them if necessary.

But I suppose that's not really answering the implicit challenge, is it?

If I had to make a counter-proposal, I'd probably have to suggest "#4": 
the cancel & exit EXCEPTIONS have names. They can be caught AND 
FINALIZED (legally not re-thrown) BY NAME (only). If caught anonymously, 
they must be re-thrown. I don't like automatically re-throwing on 
destruction (though it's a clever compromise for some scenerios, I'm 
trying to approximate some abstract idealism here so we'll discount 
that), so destruction (e.g., 'catch(...)' without a rethrow) should 
abort with some brilliantly enlightening usage message.

Where things get complicated is dealing with destructors, 'throw' and 
and nothrow clauses. I don't know; and I tried to write up paragraphs of 
ideas a few times, but deleted them. Managing a dynamic scoping system 
by throw clauses has some merit -- no throw restrictions, or a throw 
specification that includes cancel, makes the frame cancellable; nothrow 
or a throw clause omitting cancel is non-cancellable. (This might make 
large chunks of code that ought to be, or even want to be cancellable, 
non-cancellable.)

(I'm sure I'll be thrilled to be greeted by the followup when I get back 
on the 25th!)
-------------- 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/8ae1ca1c/attachment.vcf>