Cliff Woolley wrote:
I'm trying to decide whether apr_bucket_alloc should take a length parameter or not. If it takes a length parameter, it can allocate in a few different increments (say 16B, 32B, 64B, 128B), but of course it will have to have separate free lists for each thread for each size. That would allow it to allocate space for the apr_bucket_(heap|pool|file|mmap) private structures with the same system that allocates for the apr_bucket's. Or it can just use a single size (64B should be sufficient for all current bucket types), and if sizeof(apr_bucket_foo)>64, it will fail. But that seems pointless to me because we're testing at runtime a condition that's known at compile time [it may or may not be able to be compiled away depending on whether apr_bucket_alloc gets inlined or not]. But at least if we test it we can avoid situations where maybe a structure is 40B on a 32bit system but blows up to 72B on a 64bit system. If it weren't for that possibility, I'd just say we should leave it up to the developer to ensure his structure is within the allowed size and not check it explicitly, so we could just leave off the size parameter. So we'd end up with one free list, all blocks allocated would be the same size. That's clearly the absolute fastest way to allocate these things. Is it safe?
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?
--Brian
