This is the mail archive of the
mailing list for the GCC project.
Re: [basic-improvements] try/finally support for c/c++
- From: Mike Stump <mrs at apple dot com>
- To: Matt Austern <austern at apple dot com>
- Cc: Jason Merrill <jason at redhat dot com>, Stan Shebs <shebs at apple dot com>, Aldy Hernandez <aldyh at redhat dot com>, rth at redhat dot com, gcc-patches at gcc dot gnu dot org, jakub at redhat dot com
- Date: Wed, 6 Nov 2002 11:07:08 -0800
- Subject: Re: [basic-improvements] try/finally support for c/c++
On Tuesday, November 5, 2002, at 07:25 PM, Matt Austern wrote:
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++.
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.
may remember discussing this strategy at the ABI meetings (it gave
the forced_unwind stuff).
Thanks for the explanation, Jason. Yes, I can see that
I'm still not 100% sure that I find it completely compelling,
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