From dev-return-14884-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Tue Oct 11 21:01:34 2005 Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 27428 invoked from network); 11 Oct 2005 21:01:33 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 11 Oct 2005 21:01:33 -0000 Received: (qmail 38098 invoked by uid 500); 11 Oct 2005 21:01:32 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 38059 invoked by uid 500); 11 Oct 2005 21:01:32 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Id: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 38048 invoked by uid 99); 11 Oct 2005 21:01:32 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 11 Oct 2005 14:01:32 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of rooneg@gmail.com designates 64.233.184.196 as permitted sender) Received: from [64.233.184.196] (HELO wproxy.gmail.com) (64.233.184.196) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 11 Oct 2005 14:01:34 -0700 Received: by wproxy.gmail.com with SMTP id 71so251359wra for ; Tue, 11 Oct 2005 14:01:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=OOEOq5wprIJ5Aq7eXk78zoJQUzbCYHOhNkMx+OIaNacuxWHGkV6EucxD7raC2GtOcAfqwfzuC2jagn5LxgFy8rq+JCz0pZ8grL8RGiN4tkthBnYOPQBP1nl7dlJG7CJWLgeBg5MkcbXMJhvjYbhNH2zSL5WpXh6yUZhZph1PjZw= Received: by 10.54.106.12 with SMTP id e12mr3735079wrc; Tue, 11 Oct 2005 14:01:10 -0700 (PDT) Received: by 10.54.117.18 with HTTP; Tue, 11 Oct 2005 14:01:10 -0700 (PDT) Message-ID: <7edfeeef0510111401x2529eacbqeeeb1d81c416d94@mail.gmail.com> Date: Tue, 11 Oct 2005 14:01:10 -0700 From: Garrett Rooney Sender: rooneg@gmail.com To: "William A. Rowe, Jr." Subject: Re: [POLL] pools, apr 2.x, and beyond Cc: Brad Nicholes , dev@apr.apache.org In-Reply-To: <434C26C7.8060208@rowe-clan.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <434C0DC5.60509@rowe-clan.net> <434BCCA5.6720.00AC.0@novell.com> <434C26C7.8060208@rowe-clan.net> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N On 10/11/05, William A. Rowe, Jr. wrote: > Brad Nicholes wrote: > > > >> [ X] Improve (al la apr_prealloc) the pool API, but continue to > >> use a pool-based schema for apr's resources. > >> > >> [ ] Add apr_Xalloc/_Xrealloc/_Xfree based on alternate allocation > >> strategies, allowing support of non-pool based apr resources. > > > > What more would the latter bring to the table that couldn't already be > > accomplished through malloc(), realloc() and free()? > > In as much as apr objects need to be allocated somewhere, take for > example apr_file_open. It returns a pointer to a new apr_file_t. > > What's that allocated in? Choosing the first implies that all apr > structures continue to be pool-allocated, choosing the second would > imply that apr structures themselves could be alloc/free'd. One idea I had tossed around with Paul was that instead of a pool you pass in an "allocator object" of some sort. If that allocation object is a pool it allocates the file and sets up cleanups as we currently expect it to. If not, you are responsible for using a publicly declared cleanup function to destroy the file object. -garrett