From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30289 invoked by alias); 28 Jul 2011 20:03:02 -0000 Received: (qmail 30273 invoked by uid 22791); 28 Jul 2011 20:03:01 -0000 X-SWARE-Spam-Status: No, hits=-6.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 28 Jul 2011 20:02:46 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p6SK2kOq013956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 28 Jul 2011 16:02:46 -0400 Received: from anchor.twiddle.net (vpn-226-230.phx2.redhat.com [10.3.226.230]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p6SK2kLf015742; Thu, 28 Jul 2011 16:02:46 -0400 Message-ID: <4E31C065.1010907@redhat.com> Date: Thu, 28 Jul 2011 20:26:00 -0000 From: Richard Henderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110707 Thunderbird/5.0 MIME-Version: 1.0 To: Torvald Riegel CC: GCC Patches Subject: Re: [trans-mem] Beginning of refactoring References: <1306357828.13348.423.camel@triegel.csb> <1310221819.5106.1054.camel@triegel.csb> <1311031188.19033.1045.camel@triegel.csb> <1311031322.19033.1049.camel@triegel.csb> <4E31881D.9060000@redhat.com> <1311881779.3533.97.camel@triegel.csb> In-Reply-To: <1311881779.3533.97.camel@triegel.csb> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-07/txt/msg02592.txt.bz2 On 07/28/2011 12:36 PM, Torvald Riegel wrote: > No, this is correct because it calls the factory function in libitm_i.h. > However, the classes in method-serial.cc were named differently than > those factory functions, so I renamed them like this: > > -class serial_dispatch : public abi_dispatch > +class serialirr_dispatch : public abi_dispatch > > -class serial_dispatch_ul : public abi_dispatch > +class serial_dispatch : public abi_dispatch > > This should avoid confusion in the future. Excellent. >> Don't we need to fini the old disp? Seems there's a leak here, though >> not visible until we re-instate the non-serial methods. > > Yes, probably. However, one of the next steps on my refactoring list is > to document and change the TM method lifecycle callbacks. This will > include grouping several compatible methods (ie, those that can run > together) into method sets (e.g., global lock, multiple locks). > Switching a method within the current method set would then require no > fini(), whereas switching the method set would require a more > heavy-weight callback. > > I have put the case you raised on my to-do list, and will revisit it > when working on these lifecycle management changes. Sounds good. r~