apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Woolley <cliffwool...@yahoo.com>
Subject RE: cvs commit: apr/include apr_sms_blocks.h
Date Thu, 14 Jun 2001 01:05:11 GMT
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 Woolley
   Charlottesville, VA

View raw message