[Issac's view snipped]
Rather than commenting on your view Issac, please allow me to try again
to explain how I think it works, hopefully more clear this time:
Let's forget for a moment about buckets inside bridades, and call the
brigades themselves "entities" that are passed along.
Now think of a realworld fireman water bucket brigade, everybody passes
a bucket (entity) and usually there are several buckets (entities)
moving at the same time.
Now let's imagine that the first man in the brigade picks a new bucket
only when the last man has poured its bucket out. So at any given moment
there is only one bucket (entity) moving along the brigade.
This is exactly the situation with httpd. In the current httpd filtering
model one entity is moving along the filters stack and no new entity
will enter the stack, before the one on the stack will leave it (go to
the client if we are talking about output filters).
I didn't want to use the httpd buckets and brigades in this example,
because they make my comparison confusing. In the real world there is
one brigade and many buckets. In httpd, there are many bridages that are
moving along the stack of filters (and each brigade have one or more
buckets, which are irrelevant to this particular discussion).
Hope this clearifies the picture.
The conclusion: If the filter stack is busy processing some data and the
response handler hasn't finished sending the data, it'll block waiting
for the filter stack to return and only then hand over the next chunk of
data. At least that's how it appears to the filters.
Now if you want to play with it, it should be a trivial thing to do.
Just take some response handler that generates a lot of data in a loop
and prints some logs to STDERR on each iteration, then insert a filter
that passes the brigades unmodified (like MyApache::FilterSnoop does)
but has a 'sleep 3' statement. I expect that the response handler will
block on each sleep. I hope that my understanding was correct :)
Also allow me to suggest that reading the following section:
http://perl.apache.org/docs/2.0/user/handlers/filters.html#All_in_One_Filter
and trying the MyApache::FilterSnoop module at work should clearify a lot.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
- mod_perl 2.x vs. mod_perl 1.x benchmarks Josh Chamas
- Re: mod_perl 2.x vs. mod_perl 1.x benchmarks Perrin Harkins
- Re: mod_perl 2.x vs. mod_perl 1.x benchmarks Josh Chamas
- Re: mod_perl 2.x vs. mod_perl 1.x benchmark... Ask Bjoern Hansen
- Re: mod_perl 2.x vs. mod_perl 1.x bench... siberian
- possibly [OT] - changing the handler fo... iudicium ferat
- Re: possibly [OT] - changing the h... iudicium ferat
- Re: mod_perl 2.x vs. mod_perl 1.x bench... Frank Wiles
- default Content-Length calculation... Stas Bekman
- Re: default Content-Length cal... Issac Goldstand
- Re: default Content-Length... Stas Bekman
- Re: default Content-Length... Issac Goldstand
- Re: default Content-Length... Stas Bekman