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 -------------------------------------------------------------- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA