This is the mail archive of the gcc-patches@gcc.gnu.org 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++ - more tests


On 07-Nov-2002, Jakub Jelinek <jakub@redhat.com> wrote:
> On Thu, Nov 07, 2002 at 10:29:21PM +1100, Fergus Henderson wrote:
> > On 06-Nov-2002, Geoff Keating <geoffk@geoffk.org> wrote:
> > > Richard Henderson <rth@redhat.com> writes:
> > > 
> > > > On Wed, Nov 06, 2002 at 03:32:20PM -0800, Mark Mitchell wrote:
> > > > > I do not think we should add exception support of any kind to GNU C; use
> > > > > C++ if you want exceptions.
> > > > 
> > > > See elsewhere about resistance compiling libc with a c++ compiler.
> > > 
> > > It wouldn't work, anyway.  User programs can also use
> > > pthread_cleanup_push/pthread_cleanup_pop, in C, so whatever mechanism
> > > is used for that must be accessible to C.
> > 
> > How about the following?
> > This uses the C++ compiler's exception support, and is accessible from C.
> > It makes use of the GNU C nested function extension.
> > The main drawback that I can see is that it is not as efficient as possible.
> 
> s/not efficient as possible/completely inefficient/.

I agree that this approach is not efficient.

Describing it as "completely inefficient" is going a bit too far, IMHO.
Cleanups are most often used to protect code which acquires locks or
makes system calls, aren't they?  Isn't acquiring a lock or making a
system call a fairly expensive operation anyway?

The worst cause of inefficiency for this approach is probably the icache
flush needed for the trampoline creation when you take the address of a
GNU C nested function.  (I would like to see a different extension to fix
that: one that allowed you to take the address of a nested function in
a way that gave you two pointers -- a code pointer and a data pointer --
rather than a single pointer to a trampoline.)

> This would slow e.g. stdio a lot.

I was not saying that this code should be used for stdio.
I was just refuting the claim that "it wouldn't work".
Stdio (and other performance-critical routines that need cleanups)
could be implemented in C++.  These macros could be implemented
differently (more efficiently) for C++.

Now, all that said, I would like to see support for exception handling
in GNU C (and for glibc to continue to be written in C rather than C++).
But I would like the support for exception handling to include support
for throwing and catching exceptions, not just try/finally.  The current
proposal seems too limited to be useful for much else than glibc, IMHO.

> Plus it is incorrect too as pthread_cleanup_p{ush,op} implementation - the
> cleanup is to be run if cancellation happens no matter whether __call_cleanup
> is zero or non-zero.

Details, details ;-)

Sorry, I misread the spec for pthread_cleanup_{push,pop}.  But this
point can easily be remedied.  The code I posted was just proof of
concept, really.

"Designing grand concepts is fun, finding nitty little bugs is just work"
-- Brooks, in "The Mythical Man-Month".

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.


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