apr_palloc: What about apr_pfree?

[HOR <ho...@skynet.com.br>]

	Hi,

	There is a possibility of the APR team add a function like

/** Free the given pointer.  */
APR_DECLARE(void *) apr_pfree(apr_pool_t *pool, void *pointer)

to the current pool system? AFAIK it is only possible to deallocate memory 
deallocating the whole pool.

	I missing something obvious here?!

	Thanks in advance

	HOR

Re: apr_palloc: What about apr_pfree?

[HOR <ho...@skynet.com.br>]

	Thanks for the answer.

	So let me ask something else: How does people usually write applications 
using APR that can execute operations like die() (when something goes wrong) 
but need to keep the allocate memory amount under control? I mean, our server 
need to perform allocations and deallocations while executing a pretty 
expensive search. When something goes wrong, the ofending thread just call a 
die() like function and the server keeps running. The problem is: not 
perfoming the deallocations makes  the memory consumption unacceptable. Not 
using memory pools and calling a die() like function when something goes 
wrong can cause memory leaks...

	Is APR appropriate to such scenario?

On Wednesday 25 June 2003 07:19, Brian Pane wrote:
> The pool design currently can't support this.  It's optimized
> for allocation speed; in the common case, apr_palloc requires
> only a pointer addition.  The downside of this design is that
> there's no way to reclaim memory within a pool.
>
> There's been talk in the past of trying a more general-purpose
> allocator design, or a system to allow different allocators to
> be plugged in on a per-pool basis, but there's nothing like that
> in the code yet.
>
> Brian
>
> HOR wrote:
> >	Hi,
> >
> >	There is a possibility of the APR team add a function like
> >
> >/** Free the given pointer.  */
> >APR_DECLARE(void *) apr_pfree(apr_pool_t *pool, void *pointer)
> >
> >to the current pool system? AFAIK it is only possible to deallocate memory
> >deallocating the whole pool.
> >
> >	I missing something obvious here?!
> >
> >	Thanks in advance
> >
> >	HOR

Re: apr_palloc: What about apr_pfree?

[Brian Pane <br...@apache.org>]

The pool design currently can't support this.  It's optimized
for allocation speed; in the common case, apr_palloc requires
only a pointer addition.  The downside of this design is that
there's no way to reclaim memory within a pool.

There's been talk in the past of trying a more general-purpose
allocator design, or a system to allow different allocators to
be plugged in on a per-pool basis, but there's nothing like that
in the code yet.

Brian

HOR wrote:

>	Hi,
>
>	There is a possibility of the APR team add a function like
>
>/** Free the given pointer.  */
>APR_DECLARE(void *) apr_pfree(apr_pool_t *pool, void *pointer)
>
>to the current pool system? AFAIK it is only possible to deallocate memory 
>deallocating the whole pool.
>
>	I missing something obvious here?!
>
>	Thanks in advance
>
>	HOR
>  
>

Re: apr_palloc: What about apr_pfree?

[Greg Stein <gs...@lyra.org>]

On Fri, Jun 27, 2003 at 01:42:10PM -0700, Aaron Bannert wrote:
> 
> On Tuesday, June 24, 2003, at 08:41  PM, HOR wrote:
> >	There is a possibility of the APR team add a function like
> >
> >/** Free the given pointer.  */
> >APR_DECLARE(void *) apr_pfree(apr_pool_t *pool, void *pointer)
> >
> >to the current pool system? AFAIK it is only possible to deallocate 
> >memory
> >deallocating the whole pool.
> >
> >	I missing something obvious here?!
> 
> If you need malloc()/free() semantics, then you should just use
> malloc() and free(). Pools are designed to minimize and amortize the 
> cost
> of managing the free list in a way that performs very well with short
> lived "pools" of memory allocation.

Right.

I've checked in a document which talks about the "proper" pattern of using
pools. You can see the doc at:

    http://cvs.apache.org/viewcvs/*checkout*/apr/docs/pool-design.html


Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Minor documentation updates

["Marc M. Adkins" <mm...@Doorways.org>]

I've done some minor bits of documentation update:

  include/apr_file_info.txt
	warning about cross-platform incompatibility in timestamps
	vs. system time (previously submitted but not in CVS at this time,
	maybe there's a pushback on it)

  include/apr_lib.txt
	documentation of apr_vformatter so it is now more readable and
	has escape sequences listed instead of just extensions
	(I had to go to the code to find the 'q' modifier)

  include/apr_strings.txt
	added links to apr_vformatter() from other functions that
	discussed it, just makes it easier to track it down from the doc

Nothing major, just figured I could do them and save someone else the
trouble.  If they're good enough someone needs to submit them for me.  If
they suck there's always a convenient bit bucket.

mma

Re: apr_palloc: What about apr_pfree?

[Aaron Bannert <aa...@clove.org>]

On Tuesday, June 24, 2003, at 08:41  PM, HOR wrote:
> 	There is a possibility of the APR team add a function like
>
> /** Free the given pointer.  */
> APR_DECLARE(void *) apr_pfree(apr_pool_t *pool, void *pointer)
>
> to the current pool system? AFAIK it is only possible to deallocate 
> memory
> deallocating the whole pool.
>
> 	I missing something obvious here?!

If you need malloc()/free() semantics, then you should just use
malloc() and free(). Pools are designed to minimize and amortize the 
cost
of managing the free list in a way that performs very well with short
lived "pools" of memory allocation.

-aaron

RE: apr_palloc: What about apr_pfree?

["Marc M. Adkins" <mm...@Doorways.org>]

> 	There is a possibility of the APR team add a function like
>
> /** Free the given pointer.  */
> APR_DECLARE(void *) apr_pfree(apr_pool_t *pool, void *pointer)
>
> to the current pool system? AFAIK it is only possible to
> deallocate memory
> deallocating the whole pool.
>
> 	I missing something obvious here?!

I found (as a user) that I had to adjust my expectations, not necessarily in
a bad way.  If you can think about your problem as a series of recurring
transactions, then you can wrap a pool around every transaction.  The
transaction starts, you allocate a pool for it, work with the pool, then
when the transaction ends all the allocated storage just goes away with the
pool.  For long-running transaction-based processing (gee, like a web
server, eh?) memory pools work really well.

Of course any application will have persistent, global-type data.  This goes
into a global pool and never goes away.  Not generally an issue.

Where pools break down is in the allocation/deallocation of many small items
that aren't easily encompassed by transactions.  Your application may be
like that, in which case you'll have some trouble.

With luck, however, it's just a matter of getting the right perspective on
the problem.

mma