apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@covalent.net>
Subject Re: apr_bucket_alloc prototype
Date Tue, 25 Sep 2001 05:12:26 GMT
On Monday 24 September 2001 08:39 pm, 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?
> Thoughts?

If we made people register their bucket types like we used to, this problem 
would be easy to solve, because we could just take the max of all registered

I was thinking of telling you to make the code just adapt, but that is just going
to be very ugly code.  So, then I was thinking of doing it all with macros, but I
can't really see a good way to do that.

So, I'm still thinking about this.


Ryan Bloom				rbb@apache.org
Covalent Technologies			rbb@covalent.net

View raw message