httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgaudet-list-new-ht...@arctic.org>
Subject Re: [module porting] mod_proxy
Date Tue, 14 Mar 2000 19:44:21 GMT
On Mon, 13 Mar 2000, Philippe M. Chiasson wrote:

> That's true, but the problem is still there, even if it's a lightweight
> httpd (non-mod_perl) serving the request, it's gonna be stuck for a while
> with slow users anyway.  I know it's always been like that anyway, but
> it's just something I was thinking about.

you should go back in the new-httpd archives to around jun 1999 and search
for everything with MPM in the subject or "async" in the body.  and
there's also some notes about async mpms in the 2.0 src/doc directory.

the general idea is that there would be an asynchronous engine
specifically for returning responses, and a pool of threads would do the
protocol processing.  you can pretty much break up all protocols into a
series of steps like this:

1. accept new connection
2. wait for data from client
3. parse client request, determine which static object to respond with,
   or generate a dynamic object to respond with
4. send the object back to the client
5. goto 2

steps 1, 2, 4, and 5 can be handled easily with async i/o, which is as
fast as you'll get them.  (for a proxy, step 4 might be copy from TCP to
TCP).

step 3 is where all the "hard" coding goes, and it generally sucks to do
async i/o programming for this stuff.  so step 3 is handled by a pool of
threads.

that's the idea... i lost steam though, so i never implemented it.  now
i'm essentially hoping to evangelise it enough so that someone else will
jump in and do it :)

Dean


Mime
View raw message