apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Reid" <dr...@jetnet.co.uk>
Subject Re: cvs commit: apr/include apr_sms_blocks.h
Date Thu, 14 Jun 2001 01:33:47 GMT

This will need a parent, so the following could/should be the way to go (I'd
think but it's 2 am here and Ben supplied a few beers this evening :))

pms = apr_sms_std_create
bms = apr_sms_blocks_create
ams = apr_sms_?

The bucket structures are done from bms, allocations for data can come from
either ams (some other type of sms yet to be added) or from the pms using
plain old malloc.  8192 gives us space for 127 bucket structures per thread.
If we need more we can always add a method to get more, but given that it'll
only be used for a single thread and be reset between each connection (if
I've got that right) then this should be enough, shouldn't it?

If we need to make it bigger we can, but we should try to avoid adding a lot
of extra when it won't be needed if we can avoid it.

Anyway, grist for the mill to discuss on Friday :)


----- Original Message -----
From: "Cliff Woolley" <cliffwoolley@yahoo.com>
To: "Sander Striker" <striker@samba-tng.org>
Cc: <dev@apr.apache.org>; "David Reid" <dreid@jetnet.co.uk>
Sent: Thursday, June 14, 2001 2:05 AM
Subject: RE: cvs commit: apr/include apr_sms_blocks.h

> On Thu, 14 Jun 2001, Sander Striker wrote:
> > > memory, and all 8 blocks are allocated.  When we ask for a 9th one,
> > > 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
> > > check for calloc() at all and can just assume it exists.  The buckets
> >
> > Just to be safe...
> Whatever.  I guess it's there already, so no sense taking out a feature.
> =-]
> --Cliff
> --------------------------------------------------------------
>    Cliff Woolley
>    cliffwoolley@yahoo.com
>    Charlottesville, VA

View raw message