apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <bp...@pacbell.net>
Subject Re: apr_bucket_alloc prototype
Date Tue, 25 Sep 2001 04:22:04 GMT
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

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?


View raw message