apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marc M. Adkins" <mma...@Doorways.org>
Subject RE: apr_palloc: What about apr_pfree?
Date Wed, 25 Jun 2003 08:27:07 GMT
> 	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


Mime
View raw message