apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Woolley <cliffwool...@yahoo.com>
Subject Re: freelists: a slightly different approach
Date Thu, 27 Sep 2001 00:00:41 GMT
On Wed, 26 Sep 2001, Brian Pane wrote:

> >The fact that we implement any type of freelist
> >shouldn't be exposed externally outside of the bucket code - it
> >should remain hidden.  I think the external API to the buckets
> >must remain the same.
> >
> I disagree.  We typically don't make APR data structures responsible
> for their own memory management; rather, most things require that the
> caller provide an appropriate pool, because the application can make
> better choices about threads and resource management.  I think the
> same pattern can be applied to buckets; the only exception is that
> they need a free-list instead of a pool.

This is clearly the key to explaining why this is the right design.
Don't think of it as a bucket freelist.  Just think of it as a highly
specialized pool.  That's all it really is anyway.  So what we're doing
here is exactly like what all of the rest of APR does.  apr_initialize()
returns the global pool.  The caller is responsible for hanging onto that
and passing it (or a child of it) in to any APR functions that needs to
allocate some space.  It's _exactly_ the same.

[I'll reiterate my agreement that it should be a pointer to the allocation
object and not some arbitrary index int.]


   Cliff Woolley
   Charlottesville, VA

View raw message