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 buckets. 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 ______________________________________________________________ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --------------------------------------------------------------
