From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7427 invoked by alias); 8 May 2003 21:18:36 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 7406 invoked from network); 8 May 2003 21:18:34 -0000 Received: from unknown (HELO lacrosse.corp.redhat.com) (66.187.233.200) by sources.redhat.com with SMTP; 8 May 2003 21:18:34 -0000 Received: from prospero.boston.redhat.com (sebastian-int.corp.redhat.com [172.16.52.221]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h48LHji06464; Thu, 8 May 2003 17:17:45 -0400 Received: by prospero.boston.redhat.com (Postfix, from userid 4046) id A65C4F8EB7; Thu, 8 May 2003 17:16:50 -0400 (EDT) To: Mark Mitchell Cc: Alexandre Oliva , Mike Stump , gcc@gcc.gnu.org, Jason Merrill Subject: Re: __attribute__((cleanup(function)) versus try/finally From: Jason Merrill In-Reply-To: <1052423229.3329.125.camel@minax.codesourcery.com> (Mark Mitchell's message of "08 May 2003 12:47:09 -0700") References: <1052419221.3329.111.camel@minax.codesourcery.com> <1052423229.3329.125.camel@minax.codesourcery.com> Date: Thu, 08 May 2003 21:18:00 -0000 Message-ID: User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-05/txt/msg00836.txt.bz2 On 08 May 2003 12:47:09 -0700, Mark Mitchell wrote: > I agree that all of this is parenthetical; the key question is whether C > needs to have EH constructs or not, not which particular constructs they > are. I think it does. If we want to be able to interleave pthread cleanups from C and C++ exception handling, then the C code needs to interface with the EH runtime somehow; the obvious way to accomplish this is to use EH for cleanups in threaded C code. For a target that uses sjlj exceptions, this can have exactly the same overhead as the old mechanism. For a target that uses unwind tables, the normal case should be slightly faster than in the old mechanism, since we don't need to call the pthread library to register the cleanup. Code size should be similar. The main overhead is the unwind tables, which just take up disk space unless they're needed. And there's more and more precedent for always emitting unwind tables (ia64, x86-64). I don't see any compelling reason to consider inventing a new mechanism. Jason