apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <stri...@apache.org>
Subject RE: [ADDON] apr_malloc/apr_realloc/apr_free on per pool basis
Date Wed, 19 Dec 2001 18:39:09 GMT
> From: Ryan Bloom [mailto:rbb@covalent.net]
> Sent: 19 December 2001 19:32

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

We couldn't get the SMS code up to speed (which might be simply caused by
a design mistake), which was one of the problems.  Making httpd go slower
was unacceptable.

Secondly, a patch to make the server run only sms (not through the extra
pools fake up we put in place) would be huge.  Don't get me wrong, it could
be done, but noone was enthusiastic enough to do it.

To get back to the performance issues: it will be very hard for any SMS
implementation to defeat pools.
 
> Ryan

Sander


Mime
View raw message