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 04:26:49 GMT
On Thu, 14 Jun 2001, David Reid wrote:

> 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?

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



Mime
View raw message