Cliff Woolley wrote:
On Mon, 24 Sep 2001, Brian Pane wrote:
Is it always going to be true that all the bucket subclasses are declared in apr_buckets.h? If so, how about doing something like this:
union bucket_size { struct apr_bucket t1; struct apr_bucket_heap t2; struct apr_bucket_pool t3; /* rest of the bucket types omitted for clarity... */ };
and using sizeof(union bucket_size) as the single block size for the free list?
That's a very good start... the only problem is that we have no way to know how much space custom bucket types will need. As long as the space requirement is "reasonable," I think we should provide for it. If the definition of reasonable that we choose is <=sizeof(union bucket_size), then that's okay with me. Or maybe it should be the size of the union or, say, 64B, whichever is bigger? Should we even bother?
Well, it's easy to add a char[64] field to the union to make sure it's at least that large, but I'm still worried that specifying a byte size limit for custom bucket subtypes makes portability difficult.
The only other ideas that I can think of are:
* Create a convention whereby each bucket subtype has to call a function to register its size at runtime, or
* Let the free list adaptively figure out the maximum size that needs to be supported in the current program: Start out the block size at sizeof(union bucket_size), and increase it if there's ever an alloc larger than that. And if blocks smaller than the current size are freed (meaning that the block size has increased since they were allocated), just free them to the system heap instead of putting them back on the free list. In the httpd, this approach probably would settle at a stable block size after the first request or two for each thread.
--Brian
