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
