Issac Goldstand wrote:
----- Original Message ----- From: "Stas Bekman" <[EMAIL PROTECTED]>
From a quick read through:. Since if your mod_perl handler sendsthe data to a thread which runs a filter that send the data to a client (and doesn't need perl) it'll still block on the network transfer, which will block the response handler sending the data. So I can imagine that we will need a special filter that buffers the data, immediately releasing the perl handler and then slowly feeding it to the the client.This isn't just a mod_perl thing, either. This would be a generic Apache2 thing. *ANY* content should be filtered as such through a 2-tier system like this - but I thought that's what the bucket brigades did. Please correct me if I'm wrong in this picture: Response Handler ----> start of buckets ----> Filter API ----> End of buckets ----> Core Output ----> client it was my understanding that one of the purposes of the core-output filter was to do exactly what we want - free the backend request and filter threads once they've finished with the EOS bucket. Am I missing something?
server/core.c:static apr_status_t core_output_filter(ap_filter_t *f, apr_bucket_brigade *b)
I don't think core_output_filter does anything to buffer up the data and release the handler. The only buffering it does is if it doesn't have *enough* bytes to send so it waits for the next brigade.
In order to understand how the new model works you really have run the snooping filter and study the output. The important outcome that you gain is that filters are called in a pipeline, i.e. the response handler sends a portion of data to the first filter, which immediately passes that data to the next filter, and so on, while all previous filters that have already passed the first chunk await for the latter filters to return. That's my understanding so far, please correct me if I'm wrong.
So if you want to release the handler asap, you need a filter that will buffer up the data and feed it to the remaining filters at the speed they request. It should probably be inserted just before the core_output_filter, so all the processings will be already completed by that time. Think of it as an extension to the core_output_filter which buffers things up. And the cool thing is that you can inject it only when you want it, e.g. you don't want it for non-mod_perl requests.
And of course it's not mod_perl specific like you've mentioned, but I don't really know of any other producers that consume a lot of memory and therefore for which we want to minimize their number and keep them busy for real all the time.
__________________________________________________________________
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
