apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@covalent.net>
Subject Re: [ADDON] apr_malloc/apr_realloc/apr_free on per pool basis
Date Wed, 19 Dec 2001 18:32:00 GMT
On Wednesday 19 December 2001 10:20 am, Mladen Turk wrote:
> ----- Original Message -----
> From: "Sander Striker" <striker@apache.org>
> To: "Mladen Turk" <mturk@mappingsoft.com>; <dev@apr.apache.org>
> Sent: Wednesday, December 19, 2001 6:47 PM
> Subject: RE: [ADDON] apr_malloc/apr_realloc/apr_free on per pool basis
> > I have a patch to add apr_prealloc and apr_pfree to pools.  These
> > will cause some slowdown though*, so I don't know if they're worth
> > it.  I'll post them for inspection .
> >
> > This patch might be an alternative, but I don't really like that you
> > have to specify how big your chunk of mem is going to be in total.
> > Led me to think: why don't you just alloc the chunk and use it.
> > Maybe I'm missing something though,
> >
> > Sander
> >
> > *) Which I think we want to avoid.
> >
> Well, the current pool scheme sucks...
> Does someone thinks that my IQ is to low to decide when there is some memory
> location that needs to be feed?
> If I'm wrong, my program will crash, but the rest of the world will go on (I
> hope).

The real problem is that pools are too closely tied to long-lived servers, and
potentially to HTTP servers specifically.  Remember, that pools aren't supposed
to help decide when to allocate more memory.  The whole point of pools is to
allow you to never have to allocate memory, because you already allocated it
and you can just re-use it.

The biggest mistake I ever made with APR, was designing pools into it so
tightly.  Now, we are forced to layer code on top of pools to turn them into
something they were never meant to be.  :-(  I would much rather look at the
stacked memory allocation scheme we started a while ago, and see if there
is some way to make it do everything we want.  My original complaint about
that code, is that in Apache, we were using both pools and the stacked
memory, which was incorrect.


Ryan Bloom				rbb@apache.org
Covalent Technologies			rbb@covalent.net

View raw message