Message-ID: <005801bf4593$7fa3e620$1e80000a@avantgo.com>
From: "Scott Hess" <scott@avantgo.com>
To: <new-httpd@apache.org>
References: <38552F02.56746DC9@crosstor.com>
Subject: Re: Memory management in 1.3.x
Date: Mon, 13 Dec 1999 09:57:19 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org
Status: O

My suggestion would be to write a malloc()/free() replacement, and
use -Dmalloc=my_malloc -Dfree=my_free to replace the current uses.  The use
of pools you suggest seems like it would have rather high overhead for
those platforms which already have a suitable malloc library.

Later,
scott

----- Original Message -----
From: Tom Harrington <tph@crosstor.com>
To: <new-httpd@apache.org>
Sent: Monday, December 13, 1999 9:38 AM
Subject: Memory management in 1.3.x


> I'm porting 1.3.x to an embedded OS with some rather non-Unixish (and
> non-NTish, for that matter) restrictions on memory allocation.  Despite
> the differences I think it's possible.
>
> What would make this a whole lot easier would be if I could eliminate
> all calls to malloc() and the like outside of src/main/alloc.c, forcing
> all memory requests to go through the memory API.  These malloc() calls
> will need to be rewritten in one way or another if this port is to
> succeed, and it looks like the best solution is to replace them with
> calls like ap_palloc wherever possible.
>
> So I'd like some feedback on the wisdom of changes like the following:
>
> * When a malloc() appears, replace it with:
> pool *ptmp;
> ptemp = ap_make_sub_pool(NULL);
> foo = ap_palloc(ptmp, ....);
>
> * If a corresponding free() appears, replace it with
> ap_destroy_pool(ptmp);
>
> It appears that this may not work in all cases, but every little bit
> helps.
>
> --
> Tom Harrington
> CrosStor Software, Inc.
> tph@crosstor.com