apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Woolley <cliffwool...@yahoo.com>
Subject apr_bucket_alloc prototype
Date Tue, 25 Sep 2001 03:39:22 GMT

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?

Thoughts?

--Cliff

--------------------------------------------------------------
   Cliff Woolley
   cliffwoolley@yahoo.com
   Charlottesville, VA



Mime
View raw message