apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "HOR" <...@skynet.com.br>
Subject Re: apr_palloc: What about apr_pfree?
Date Wed, 25 Jun 2003 04:52:49 GMT
	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

View raw message