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:[EMAIL PROTECTED] > 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" <[EMAIL PROTECTED]> > To: "Sander Striker" <[EMAIL PROTECTED]> > Cc: <dev@apr.apache.org>; "David Reid" <[EMAIL PROTECTED]> > 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 > > [EMAIL PROTECTED] > > Charlottesville, VA > > > > > > >
