On the opposite, IMHO this is very ON topic, since that's the core of the 2.0.Well, it's been getting *WAY* OT - more geared for dev@httpd if anywhere, but I'm sure they've argued this out already :-) My initial ideas all counted on the fact that each handler/filter would have a way of getting its own per-request thread...
That's the real pipeline. But it'll be only useful if you have many CPUs. I remember reading somewhere, that on a single CPU sequential processing might be faster rather than pseudo-parallel, because of the context-switch overhead. Though admittedly it's much smaller with threads, but depends on the implementation.there is a talk about async I/O mpms for 3.0, or later 2.xThis sounds like our "many buckets with firemen" scenario - but, again, it only really becomes useful if the handlers/filters have their own thread running space.
Now, nothing prevents you from developing your own mpm right now or at any time latter that will do what you want. It's actually much easier that it seems to be because a big chunk of functionality is abstacted away. So it's not like writing an Apache server from scratch. I admit that I haven't written my own mpm yet and that's the impression that I have from reading posts at httpd-dev.
Yes and no. Remember that our perl interpreters live in a separate pool of threads, so if we can release them asap, they can go and serve more requests, while the filters do whatever they do. Since the perl interpreters don't reside on the same thread that serves the connection.But the conclusion I'd draw from this, getting back to the original question, is that under Apache 2, it's *still* worth doing a frontend/backend setup where the frontend buffers all the backend data. Even if we *did* write the buffer filter, if the whole pipeline is stuck in one thread, then we're not freeing up the resources when the heavy handler/filter is done, so slow clients will still clog server resources.
Though you are correct that the response handler won't be released until the filters will be done. So we need to think of some trickery to release the response handler earlier.
Sure, there is nothing wrong with front/end backend setup, it just makes things a bit more complicated to setup and maintain. So if we can provide an alternative solution that requires only one server, that would be cool.The frontend/backend solution takes care of this, because here, we're creating our own 2-threaded pipeline: the important thing being that the frontend should either have a buffer filter, or better yet, a "constant flush + buffer" filter to get the data from the backend straight to the client, while buffering additional data if needed. Does this make sense to you?
That's said let's worry first to get the core things working first and if you want to play with optimizations please go ahead and hack away :)
__________________________________________________________________
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
