apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <bp...@pacbell.net>
Subject Re: freelists: a slightly different approach
Date Wed, 26 Sep 2001 23:51:11 GMT
Justin Erenkrantz wrote:


>>There is no reason for either a linked-list or hashtable.  This should be a simple
>>array.  We are talking about 1 pointer per slot in the array, allocated once.
>>Assume a 64-bit platform, for a worst case scenerio, and 2000 threads per 
>>process, and you have 1600 bytes for the static allocation.
>No, I don't believe it should be an array because you are requiring
>the arrays to be created by the user of the buckets.  I think that
>is completely bogus.  The user of the bucket code shouldn't care
>diddly-squat about the fact that the bucket code implements a
>freelist.  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.


>I think you are blurring the distinction between APR and httpd.
>Yes, you could create an array full of opaque data structures in
>httpd and pass that in to the bucket functions - I am merely 
>stating that I believe that is broken API.

I agree on this part; I'd much rather require the app to pass in
an apr_bucket_free_list* than some numeric ID that gets mapped to
a free list.  If the app wants to keep its free lists in an array,
that's fine, but it's cleaner if the bucket allocation code only
sees the one relevant apr_bucket_free_list*.


>I'm beginning to wonder whether we even need per-thread 
>freelists at all.  Our pools don't have them.  Take this
>conversation and extend it to pools (i.e. when you create
>a pool, you pass in a caller-defined freelist) seems even
>more disturbing.  -- justin

The *only* reason we've gotten this far without per-thread
free lists for pools is that most apr_palloc() calls in the
httpd happen to be small enough to work without additional
block allocations from the global free list.  In general, I
don't think it's a bad idea to provide an alternate API for
pool creation that says, "give this pool and its children
a private, non-mutex-protected free list."


View raw message