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."
--Brian
