apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mladen Turk" <mt...@mappingsoft.com>
Subject Re: [ADDON] apr_malloc/apr_realloc/apr_free on per pool basis
Date Wed, 19 Dec 2001 20:29:34 GMT

----- Original Message -----
From: "Ryan Bloom" <rbb@covalent.net>
To: "Mladen Turk" <mturk@mappingsoft.com>; "Sander Striker"
<striker@apache.org>; <dev@apr.apache.org>
Sent: Wednesday, December 19, 2001 7:32 PM
Subject: Re: [ADDON] apr_malloc/apr_realloc/apr_free on per pool basis


> 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.
>

I understand that 100%, but as you said, lets go further... I think of apr
as the best peace of code that I've ever seen. The pools as concept is
excellent, but IMO there has to be the way that someone use the apr as a
genereral libc. For example try to implement a simple recursive sorting
algorithm using apr, and you will end up with cca. 1GB for a 10000 elements.
IMO there has to be some kind of a implicit free, or the apr will become
something like java or vb that no-one really knows how the bugger really
works.

In general I only want to be able to do a simple thing like:
!SYSTEM.FREEMEM 101000
char *dummy = apr_palloc(somepool, 1000);
!SYSTEM.FREEMEM 100000
apr_pfree(somepool, dummy);
!SYSTEM.FREEMEM 101000

and that's all...

MT.




Mime
View raw message