You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Dipak Patel <Di...@atinet.com> on 2004/01/08 03:35:24 UTC

RE: Memory pools -- support for moving a sub-pool from one pool t o an other

Sander and Cliff,

Thank you for your feedback. 

My comment:

>We are considering the use of APR memory pool feature in our commercial
product but I have >not been too impressed with the supportout there ..

was based on not hearing back from anyone since my first e-mail on this
subject dated December 4,2003. To date most of the code we have is either
in-house developed and maintained or licensed from a commercial vendors with
whom we have support contracts.

I really want our team to use the APR in general but we thought we would get
our feet wet with an immediate need of memory pools so that we can avoid
fragmentation under heavy loads. As with many companies, we have our own
portability layer that abstracts sockets, memory, threads, C library
functions, and other services. Bunch of us are intimate with this layer and
this allows us to release hot patches within a day or two. I would like to
see us move to APR which is worked on by many more people and used by more
users then our product but it's going to take us time to feel comfortable
with outside code.

We actually have two functions in our code:
moveTree(srcPool, dstPool) and moveItem(srcItem, dstPool). The moveItem()
takes an allocated buffer and binds it as a child of the dstPool. I
understand that this may have to be implemented by first allocating a buffer
--say dstItem-- of size srcItem in the dstPool and then doing a copy and
then freeing the srcItem. Does APR allow me to find out the size of the
srcItem if I just have the srcItem pointer.

Please let me know if you can help with the above two items so that we can
integrate and test APR pools in our code. Thanks.
 
------------------------------
Dipak M. Patel
Email:   dipakp@atinet.com   
Phone: 408-350-7038    408-350-7021 (fax)
www.atinet.com


-----Original Message-----
From: Sander Striker [mailto:striker@apache.org]
Sent: Wednesday, January 07, 2004 6:22 PM
To: Dipak Patel
Cc: 'dev@apr.apache.org'
Subject: Re: Memory pools -- support for moving a sub-pool from one pool
to an other


On Thu, 2004-01-08 at 02:46, Dipak Patel wrote:
> This is the third time I'm asking this question. Can anyone please
> tell me how to use some built in feature of the apr memory pool module
> to move a sub-pool to under another pool? Our software makes use this
> type of feature to pass messages from on layer to another where each
> layer has its own pool. We simply want to take the entire sub-pool and
> assign it to a new parent.

Doable.  Should be a fairly tiny patch to make this possible.  It would
be a 'BEWARE! USE AT OWN RISK!' feature, since you are going to mess
with lifetimes and such (and cleanup ordering since the child cleanups
happen at a different time than at original parent destroy).  Be careful
with lifetime dependencies.

> We are considering the use of APR memory pool feature in our
> commercial product but I have not been too impressed with the support
> out there.

Excuse me?  This is exactly the sort of comment that demotivates me
to write the actual patch.

Sander

Re: Memory pools -- support for moving a sub-pool from one pool t o an other

Posted by Ben Laurie <be...@algroup.co.uk>.
Sander Striker wrote:
>>We actually have two functions in our code:
>>moveTree(srcPool, dstPool) and moveItem(srcItem, dstPool). The moveItem()
>>takes an allocated buffer and binds it as a child of the dstPool. I
>>understand that this may have to be implemented by first allocating a buffer
>>--say dstItem-- of size srcItem in the dstPool and then doing a copy and
>>then freeing the srcItem. Does APR allow me to find out the size of the
>>srcItem if I just have the srcItem pointer.
> 
> No.  The memory returned by apr_palloc doesn't have any recorded size associated
> with it.  The only thing you might be able to deduce is the size of the containing
> block of memory.  But that may be a LOT larger than what you are looking for.
> Also, the concept of 'freeing the srcItem' isn't possible.  There is no
> apr_pfree function.

Of course, you could replace apr_palloc with a version that did record 
the size.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

RE: Memory pools -- support for moving a sub-pool from one pool t o an other

Posted by Sander Striker <st...@apache.org>.
On Thu, 2004-01-08 at 03:35, Dipak Patel wrote: 
> Sander and Cliff,
> 
> Thank you for your feedback. 
> 
> My comment:
> 
> >We are considering the use of APR memory pool feature in our commercial
> product but I have >not been too impressed with the supportout there ..
> 
> was based on not hearing back from anyone since my first e-mail on this
> subject dated December 4,2003.

I only see one mail prior to this one and it is a one liner on Dec 17,
2003.  The question was also phrased somewhat rethorical.

[...]
> We actually have two functions in our code:
> moveTree(srcPool, dstPool) and moveItem(srcItem, dstPool). The moveItem()
> takes an allocated buffer and binds it as a child of the dstPool. I
> understand that this may have to be implemented by first allocating a buffer
> --say dstItem-- of size srcItem in the dstPool and then doing a copy and
> then freeing the srcItem. Does APR allow me to find out the size of the
> srcItem if I just have the srcItem pointer.

No.  The memory returned by apr_palloc doesn't have any recorded size associated
with it.  The only thing you might be able to deduce is the size of the containing
block of memory.  But that may be a LOT larger than what you are looking for.
Also, the concept of 'freeing the srcItem' isn't possible.  There is no
apr_pfree function.

Moving an entire subpool to a new parent pool should be less of a problem
as I said earlier.

> Please let me know if you can help with the above two items so that we can
> integrate and test APR pools in our code. Thanks.

I'm a bit pressed for time at the moment.


Sander