Re: [basic-improvements] try/finally support for c/c++

[Mike Stump <mrs at apple dot com>]

On Tuesday, November 5, 2002, at 07:25 PM, Matt Austern wrote:
> On Tuesday, November 5, 2002, at 05:19  PM, Jason Merrill wrote:
>
> > I believe that the purpose of this stuff is to handle pthread cleanups
> > using EH so that we can implement thread cancellation using EH.  
> > Matt, you
> > may remember discussing this strategy at the ABI meetings (it gave 
> > rise to
> > the forced_unwind stuff).
> Thanks for the explanation, Jason.  Yes, I can see that
> motivation.
>
> I'm still not 100% sure that I find it completely compelling,
> though.
As I recall...  the problem is that in a C only world, existing 
pthreads implementations are fine, and in a C++ only world, EH is fine. 
 If one wants to combine those two features pthreads and C++, there is 
a slight semantic rubbing that happens.  One wants the stack cleanup 
actions of threads and the stack cleanup actions of C++ to interleave 
normally.  From the C++ perspective, the way that we insist that this 
work, is if the EH mechanism, throw, is used.  If you accept that 
design point, then you come to the conclusion that pthreads wants to 
throw an object to cleanup, so that the C++ actions run.  And from 
there, we then need to use a more EH style mechanism to register the C 
cleanups, so that they interleave nicely with C++.

We can avoid this by either mandating that pthreads and C++ should not 
be used at the same time, or by mandating non-exceptional overhead to 
track the entering and leaving of regions for C++, or by removing 
cleanups from pthreads or removing EH from C++.

So, the question isn't, do you oppose it, it is rather, which solution 
to the problem do you prefer, and why?

A design goal of the gcc family of languages has always been 
interoperability between the languages, or at least as much as 
possible.  This is one of the motivations behind wanting pthreads from 
the C world and cleanups actions from the C++ world to interoperate 
nicely.  Then both features can be used to their fullest, even in a 
complex system when C/pthreads and C++ are mixed.

The C++ world is used to the zero-overhead EH chanting, and are loath 
to give it up.  We could, but, I suspect we'd not be C++ abi compliant 
with the existing C++ abi standard.  These two points, not wanting to 
give up C++ abi, and not wanting overhead I think constrain the C world 
to need to access the EH data the C++ world creates.  From there, the 
wanting of C++ to run the cleanup actions from pthreads, means the C++ 
EH mechanism has to be able to read the data the C/pthreads 
implementation produces.  In the end, you can think about it anyway you 
want, but in reality you've just unified C/pthreads and C++ EH.  And 
once you've done that, __try/__finally or whatever you want to call it 
is just syntactic sugar on __builtin_pthread_register_cleanup or some 
other such nonsense.

Also, this isn't new or out of thin air.  It was designed and planned 
around many years years ago (5, 8?).  I think that discussion mostly 
happened on the eh list, though, some of it did happen in smaller email 
groups.  I could be mistaken, and maybe the discussions were just 
seeded off the eh list.  In that timeframe and after thinking about it, 
I don't think we found anything we like better, and apparently the 
`problem' hasn't just gone away.

I tried to recount the history of this, with a little luck it is close. 
 If I got it any of it wrong, I'm sure other will chime in and correct 
it.