From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21379 invoked by alias); 6 Nov 2002 18:25:29 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 21369 invoked from network); 6 Nov 2002 18:25:27 -0000 Received: from unknown (HELO mx2.redhat.com) (12.150.115.133) by sources.redhat.com with SMTP; 6 Nov 2002 18:25:27 -0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.11.6/8.11.6) with ESMTP id gA6INsP16800; Wed, 6 Nov 2002 13:23:54 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id gA6IPQl16622; Wed, 6 Nov 2002 13:25:26 -0500 Received: from localhost.localdomain (frothingslosh.sfbay.redhat.com [172.16.24.27]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id gA6IPPD19451; Wed, 6 Nov 2002 10:25:25 -0800 Received: (from rth@localhost) by localhost.localdomain (8.11.6/8.11.6) id gA6IPP422094; Wed, 6 Nov 2002 10:25:25 -0800 X-Authentication-Warning: localhost.localdomain: rth set sender to rth@redhat.com using -f Date: Wed, 06 Nov 2002 10:25:00 -0000 From: Richard Henderson To: Matt Austern Cc: Jason Merrill , Stan Shebs , Aldy Hernandez , gcc-patches@gcc.gnu.org, jakub@redhat.com Subject: Re: [basic-improvements] try/finally support for c/c++ Message-ID: <20021106182525.GB22066@redhat.com> Mail-Followup-To: Richard Henderson , Matt Austern , Jason Merrill , Stan Shebs , Aldy Hernandez , gcc-patches@gcc.gnu.org, jakub@redhat.com References: <5FB32E42-F137-11D6-946D-000393B2ABA2@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5FB32E42-F137-11D6-946D-000393B2ABA2@apple.com> User-Agent: Mutt/1.4i X-SW-Source: 2002-11/txt/msg00299.txt.bz2 On Tue, Nov 05, 2002 at 07:25:18PM -0800, Matt Austern wrote: > I'm still not 100% sure that I find it completely compelling, > though. Yes, I do remember the forced unwind stuff, but that > started from the question of how thread cancellation would > interact with automatic variables' destructors, which is, um, > less of a concern for C. Actually, it is a concern for libc itself. Thread cancelation is required to release various locks acquired within stdio. > After all, pthreads was designed and implemented > with standard C90 in mind; do we really need this sort of > language change either to implement pthread_cancel or for > programmers to be able to use it effectively? We have two choices: One, libpthread and libc can continue to use a setjmp/longjmp based solution, which _does_ work within the framework of C90. This, however, ignores the many many (somewhat misinformed) bug reports that complain about C++ destructors not being run at thread cancelation. Despite the fact that POSIX does not mention C++ at all, one must agree that having destructors run at thread cancelation is a highly desireable feature. Two, we can add just enough EH support in C such that we can drop the setjmp/longjmp solution and use EH alone for thread cancelation. (Apparently the glibc folk consider building libc with a C++ compiler to be an abomination. Given the sometimes subtle differences between the two languages, I can't really fault this point of view.) > (One thing I've learned since the ABI discussions, by the way, > is that asynchronous cancelation with pthread_cancel was only > designed for some extremely specialized cases... I'm talking about synchronous cancelation only. r~