Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Message-Id: <5.1.0.14.2.20020625071436.047256b8@127.0.0.1>
Date: Tue, 25 Jun 2002 07:20:34 +0300
To: Greg Stein <gstein@lyra.org>
From: Andi Gutmans <andi@zend.com>
Subject: Re: Memory manager
Cc: dev@apr.apache.org
In-Reply-To: <20020624155831.B17458@lyra.org>
References: <5.1.0.14.2.20020624230608.03c18cf0@127.0.0.1>
 <5.1.0.14.2.20020624230608.03c18cf0@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 03:58 PM 6/24/2002 -0700, Greg Stein wrote:
>On Mon, Jun 24, 2002 at 11:07:43PM +0300, Andi Gutmans wrote:
> >...
> > The APR memory pools aren't good enough for us because they don't allow
> > for any freeing which just doesn't work for PHP.
>
>Um. We use pools in Subversion and free the memory all the time. The key is
>the use of subpools. I added some notes about our experiences at the end of
>this document:
>
>     http://cvs.apache.org/viewcvs/apr-serf/docs/roadmap.txt?rev=1.3
>
>Note that pools can also be configured to not have a per-thread lock.

Ouch, you really worked hard there. That is exactly what we can't do in 
PHP. Our code base is so big that the easiest solution for us has always 
been to just give our users the memory allocation API they are used to (in 
our case emalloc(), efree(), erealloc() and so on) and just make sure that 
all of this memory gets freed at the end of each request (we also have some 
leak detection code but that is coded on top of the actual memory manager).
Also as PHP is a scripting language it can run for quite a bit and do lots 
of allocation's and free's. You can't really do any planning like you guys 
did in Subversion on exactly when stuff can be freed and when not. Grouping 
memory allocations is virtually impossible. Anyway, it does seem that you 
guys had to work a bit too hard.


> >...
> > Do you guys have any interest in adding this kind of "smarter" memory pool
> > into APR? I think it's extremely useful.
>
>Sure. Although I'm a bit unclear on how it differs from using, say,
>apr_pool_destroy on a subpool to toss intermediate memory.

If I understood correctly the difference is that you don't need to group 
the memory but can allocate and toss memory when ever you need to. This 
kind of "knowing in advance" can't be done in PHP.

Andi

P.S. - I'm enthusiastically waiting for subversion. CVS just doesn't cut it 
anymore.