On Thu, 14 Jun 2001, Sander Striker wrote: > > memory, and all 8 blocks are allocated. When we ask for a 9th one, it'd > > be much nicer to get one a little slower than to not get one at all. > > Yes, but you would have anticipated for that wouldn't you (thus setting > a large enough size)?
Not necessarily. (I'm thinking from the buckets point of view here, but that's fine since they'll be the first user of this code.) Each thread will have one of these sms's assigned to it ahead of time. Saying that you absolutely can't allocate more than (n=totalsize/blocksize) blocks is completely bogus, because that means that you absolutely cannot have more than roughly n/2 buckets in existence simultaneously in that thread, ever. That's not an acceptable restriction. > We can not just call apr_sms_malloc() on the parent for this one. > You'd have to track all the nodes that went out this way (to be able > to do the reset). If this is needed, then we'll have to implement it. I'd be willing to forego the reset function for bucket purposes, though it's nice to have for other potential users of this sms module. If you know a way to make it work, please do... it's definitely needed. > > AFAICT this doesn't need to be implemented... apr_sms_default_calloc() > > should be fine. > > Ah, yes. David and I got a bit obsessed with speed last night. This is > a bit quicker than letting apr_sms_default_calloc() handle it. Come to > think of it, if we do a single memset() in the reset we can get away > with setting both calloc_fn and malloc_fn to the same function :) Sheesh. Obsessed is right. =-) Just how much slower is the default function? It does exactly the same thing, give or take a few calls added to the stack and an if() or two. I don't see a worthwhile gain in doing it inline and duplicating the code. (The single memset() idea is good but I think it would break the instant you freed something and returned it to the list unless _free() also called memset(), but that unnecessarily penalizes callers that doesn't even USE _calloc().) > > !HAVE_CALLOC, but then again, I'm of the mind that we don't even need to > > check for calloc() at all and can just assume it exists. The buckets code > > Just to be safe... Whatever. I guess it's there already, so no sense taking out a feature. =-] --Cliff -------------------------------------------------------------- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
