From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20033 invoked by alias); 11 Aug 2003 15:45:19 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 20025 invoked from network); 11 Aug 2003 15:45:17 -0000 Received: from unknown (HELO hawaii.kealia.com) (209.3.10.89) by sources.redhat.com with SMTP; 11 Aug 2003 15:45:17 -0000 Received: by hawaii.kealia.com (Postfix, from userid 2049) id 35525BFE7; Mon, 11 Aug 2003 08:45:17 -0700 (PDT) To: Mark Kettenis Cc: gdb-patches@sources.redhat.com Subject: Re: [RFC/RFA] Per-objfile data mechanism References: <200307131717.h6DHH425098569@elgar.kettenis.dyndns.org> <20030715161729.GA32437@nevyn.them.org> <200308101903.h7AJ32Bx079942@elgar.kettenis.dyndns.org> From: David Carlton Date: Mon, 11 Aug 2003 15:45:00 -0000 In-Reply-To: <200308101903.h7AJ32Bx079942@elgar.kettenis.dyndns.org> (Mark Kettenis's message of "Sun, 10 Aug 2003 21:03:02 +0200 (CEST)") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Rational FORTRAN, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-08/txt/msg00178.txt.bz2 On Sun, 10 Aug 2003 21:03:02 +0200 (CEST), Mark Kettenis said: > From: David Carlton > Date: Tue, 15 Jul 2003 09:48:31 -0700 >> I was also going to write, based on a cursory misreading of Mark's >> patch, that it simplified memory management in some circumstances, >> but now that I look at it more closely, I think I just misread the >> patch. (I may still be misreading the patch; my head is spinning >> with other things.) Would it be possible/beneficial to modify the >> mechanism to provide an optional per-datum cleanup function as >> well? > I quite deliberately left per-datum initializers and destructors out > to encourage the use of the per-objfile obstacks. But they can > always be added if they're needed. The concrete reason for that suggestion is that I have a patch awaiting review adding some per-objfile data that consists of an expanding hash table; that can't be handled with an obstack. In general, I get the feeling that we're moving a bit more to data structures that are less obstack friendly, but who knows. Having said that: > So what's the final verdict. Should my patch go in, or do people > have concrete ideas about necessary improvements or alternative > implementations? I certainly wouldn't want to stand in the way of putting it in now: if we do decide we want to add per-datum cleanup mechanisms to your patch, we can do it just as easily after the patch has been applied as before the patch has been applied. David Carlton carlton@kealia.com