On Monday 24 September 2001 09:52 pm, Cliff Woolley wrote:
> On Mon, 24 Sep 2001, Ryan Bloom wrote:
> > > void apr_bucket_free(void *ptr, int list);
> > >
> > > But that means it'll be tricky to support the b->free(b) thing that
> > > FirstBill requested. It was nice and clean with SMS (grumble), since
> > > the function to use and the particular instance to be freed (and
> > > knowledge of its parent) were tied together as b->sms... any ideas? I
> > > suppose we could wrap free() with some other function in order to
> > > discard the extra parameter for those bucket types that might still
> > > want to use malloc/free directly... ugh.
> >
> > Why not just put the list number in the bucket itself?
>
> It already is. It's also in the apr_bucket_file/mmap/etc's so that
> file_destroy, mmap_destroy, etc, can work. Remember that I'm trying to
> use apr_bucket_alloc and apr_bucket_free to handle the
> apr_bucket_file/mmap/etc's as well as just the apr_bucket's. So unless
> the list number is at the same offset in apr_bucket_file and
> apr_bucket_mmap et al as it is in apr_bucket (which it almost certainly
> won't be), you can't just do this:
>
> void apr_bucket_free(void *ptr) {
> apr_bucket *b = ptr;
> free_the_damned_thing(b, b->list);
> }
>
> Because b->list will point to the wrong spot in the thing pointed to by
> ptr.
I have two different suggestions.
1) Put everything in the same list. When you need to grab the next bucket,
just check the alloc size to see if you can use that spot. Doing this assumes
that
we won't have too many buckets in the free list. We could optimize this a bit
by making sure the list is sorted, so that we don't always have to walk the
entire
list. We could also optimize this by making all of the standard buckets the
same
size, or at least decide on two or three sizes.
This has the advantage of solving the other problem too.
2) Keep a separate list of free_buckets for all different bucket types. This
way, the id's in each bucket type can be the same, because they all refer to
different arrays.
Ryan
______________________________________________________________
Ryan Bloom [EMAIL PROTECTED]
Covalent Technologies [EMAIL PROTECTED]
--------------------------------------------------------------
