apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Holsman <I...@cnet.com>
Subject RE: cvs commit: apr/include apr_sms_blocks.h
Date Thu, 14 Jun 2001 04:19:28 GMT
Hi David,
there has to be a method of growing the area,
or allocating set of blocks. 
The example I keep seeing is
Imagine 1000 subrequests in 1 request.
or some funky CGI whic outputs a character at a time
or even some filter which requires ALL the buckets present 
before it can send any out.. I think all of these would 
use more than 127 buckets.


..Ian

> -----Original Message-----
> From: David Reid [mailto:dreid@jetnet.co.uk]
> Sent: Wednesday, June 13, 2001 6:34 PM
> To: Cliff Woolley; APR Development List
> Subject: Re: cvs commit: apr/include apr_sms_blocks.h
> 
> 
> Cliff,
> 
> 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 :)
> 
> david
> 
> ----- 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,
> 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
> >    cliffwoolley@yahoo.com
> >    Charlottesville, VA
> >
> >
> >
> 

Mime
View raw message