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 07:56:25 GMT
OK.  I'll look at adding the capability in some sane manner :)

----- Original Message -----
From: "Cliff Woolley" <cliffwoolley@yahoo.com>
To: "David Reid" <dreid@jetnet.co.uk>
Cc: "APR Development List" <dev@apr.apache.org>
Sent: Thursday, June 14, 2001 5:26 AM
Subject: Re: cvs commit: apr/include apr_sms_blocks.h

> On Thu, 14 Jun 2001, David Reid wrote:
> > The bucket structures are done from bms, allocations for data can come
> > either ams (some other type of sms yet to be added) or from the pms
> > plain old malloc.  8192 gives us space for 127 bucket structures per
> > If we need more we can always add a method to get more, but given that
> > only be used for a single thread and be reset between each connection
> > I've got that right) then this should be enough, shouldn't it?
> One would think, but no, not necessarily.  It's possible for a filter to
> split a brigade up into a million little bitty pieces, possibly even 1
> byte per bucket (granted, that'd be a pretty stupid filter).
> [side note: I just saw Ian's post, and he has some good examples of cases
> where you could end up with lots of buckets at a time.  I'm not sure about
> the subrequests example, because each subrequest would get handled one at
> a time, its buckets being dumped out to the network and the buckets freed,
> generally.  But it could happen, I guess.]
> It occurred to me that all you have to do to handle resets is keep a list
> of the "extra" blocks you allocate and then loop through them, freeing
> each one, when the reset happens.  You end up with just the one
> pre-allocated block you started with.
> > Anyway, grist for the mill to discuss on Friday :)
> Definitely.  =-)
> --Cliff

View raw message