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:54:14 GMT
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.


View raw message