This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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

I'm still not 100% sure that I find it completely compelling,
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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]