Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: local policy)
Subject: Re: allocator and using malloc alternatives
MIME-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset="us-ascii"
From: Chris Knight <christopher.d.knight@nasa.gov>
In-Reply-To: <0CD3EB7D-FB90-469E-B046-69A53A8A3DDC@apache.org>
Date: Tue, 18 May 2010 18:58:03 -0700
CC: APR Developer List <dev@apr.apache.org>
Content-Transfer-Encoding: quoted-printable
Message-ID: <848BEEB5-85F0-4E64-BBBD-3C581CF1B4E6@nasa.gov>
References: <82967C72-7A0E-44C1-AAF7-AA866D99F87E@apache.org>
 <EA4E0A48-FD70-4980-8482-C13287DB967F@apache.org>
 <0A76B1E1-0443-46ED-B614-8ED133D7D615@nasa.gov>
 <0CD3EB7D-FB90-469E-B046-69A53A8A3DDC@apache.org>
To: Nick Kew <niq@apache.org>

Ah, makes sense. Yeah would be insane to change the malloc replacement =
mid-stream so an alternate to create_with_allocator is nice.

But you also bring up an important question; I argue that you should =
only be able to do this on a top-level pool, not on a child pool...(In =
other words, create_with_allocator would not take a parent pool =
pointer.)

On May 18, 2010, at 6:01 PM, Nick Kew wrote:

> On 19 May 2010, at 00:12, Chris Knight wrote:
>=20
>> Thanks, I mostly didn't want it to be part of apr_pool_create because =
then you'd have to change every instance of calling apr_pool_create;
>=20
> Yes of course.  It would be a separate create function, =
apr_pool_create_with_allocator
> or something similar but less verbose, and certainly nearer =
apr_pool_create_ex.
>=20
>> plus most users will not need this capability so rather not have 99% =
of apr_pool_create calls with 3 NULL's at the end. Also the semantics =
get a little confusing in doing this at apr_pool_create; is the =
apr_pool_t * allocated from the allocator_alloc_fn or via malloc()?
>=20
> :-)
>=20
> Surely, from the parent pool!  That's only a question in a top-level =
create.
>=20
> --=20
> Nick Kew