This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: EH in C (was: Re: (lack of) Thread-safe exceptions on AIX (gcc-2.95.1)
- To: Zack Weinberg <zack at wolery dot cumb dot org>
- Subject: Re: EH in C (was: Re: (lack of) Thread-safe exceptions on AIX (gcc-2.95.1)
- From: Bill Tutt <rassilon at list dot org>
- Date: Tue, 1 Feb 2000 12:47:17 -0800 (PST)
- cc: Bill Tutt <rassilon at list dot org>, Richard Henderson <rth at cygnus dot com>, llewelly at 198 dot dsl dot xmission dot com, gcc at gcc dot gnu dot org
On Tue, 1 Feb 2000, Zack Weinberg wrote:
> On Tue, Feb 01, 2000 at 02:05:59AM -0800, Bill Tutt wrote:
> >
> > The annoying thing is that C based try/catch handlers need some kind of
> > information about the exception that occurred if they want to do any
> > useful processing. So if the C based try/catch handlers can't catch
> > asynchrnous exceptions (segv, divdie by zero, etc) and information about
> > C++ based exceptions is kind of useless is there any reason we need
> > try/catch for C at all? i.e. can we get away with just a try/finally pair?
> > This avoids the GetExceptionCode() problem altogether, but leaves
> > AbnormalTermination(), but that seems like a fairly simple gcc builtin to
> > code up.
>
> The usual reason people want exceptions in C is to make pthread
> cancellation play nice with C++. The pthread library has 'cleanups'
> that happen when a thread is cancelled, that are basically
> try/finally, but they don't interoperate with the C++ exception
> mechanism. What you'd like is for pthread_cleanup_push/pop to be
> implemented in terms of try/catch, and pthread_cancel to throw an
> exception in the cancelled thread.
>
> That requires only try { } catch (...) { }, plus some way to throw
> an object (not just rethrow), in C.
>
I'm afraid I don't know anything about pthreads, although I do vaguely
recall people discussing the problem you mention. I'm just not sure I
follow why you think __try/__finally in C doesn't interoperate with the
C++ exception mechanism. Perhaps you could enlighten me more on the
details of the pthread problem?
A __finally block is simply the equivalent of a C++ destructor that needs
to get called when the exception handling mechanism is unwinding the stack
to the exception handler itself.
If you use try {} catch(...) {} you'll end up having code like this:
try
{
....
}
catch(...)
{
cleanup();
}
cleanup();
Which looks frightfully silly to me. If you're only talking about
synchrnous exception handling, I still don't see why C would need a
try/catch syntax since it doesn't have any useful understanding of the
exception state at all.
On the other hand, if you just want to avoid deviating from a subset of
the C++ syntax then you will end up having code like the above. Which I
suppose is fine, just make sure you make that design decision explicit in
the docs.
Bill