httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zach Brown <...@zabbo.net>
Subject Re: async routines
Date Mon, 28 Jun 1999 23:49:22 GMT

> [hope you don't mind me cc'ing new-httpd zach, I think others will be
> interested.]

oh, no problem at all.  the more the merrier :)

my apologies if some of this sounds dumb, I'm not terribly familiar with
the apache source yet :(

> You're still waiting for me to get the async stuff in there... I've done
> part of the work -- the BUFF layer now supports non-blocking sockets. 

could I abuse things such that I could read in a BUFF asyncly and then
mend it to a connection and pass it down the protocol layers?  If they
could return "hey dork, that buff isn't a complete request" I could then
hand it off to threads to deal with it.. 

say I set a bit in the connection struct that says "return an 'incomplete'
error rather than aborting or completing.." so that I can then clear this
bit and hand it off to a thread that will follow the usual blocking paths.

> However, the HTTP code will always remain blocking.  There's no way I'm
> going to try to educate the world in how to write async code... and since
> our HTTP code has arbitrary call outs to third party modules... It'd
> have a drastic effect on everyone to make this change.

oh, I understand that completely.  All I need is an async ability to parse
a request.. even if I have to jump through hoops to get at it.

I _certainly_ don't expect all module/cgi writers to now adapt their code
paths to understand async checkpointing and all that snot ;)

> All the popular HTTP clients send their requests in one packet (or two
> in the case of a POST and netscape).  So the HTTP code would almost

Agreed, certainly.

but my argument here is that supporting the off chance that we will block
while parsing the requests renders useless the nice nice optimizations we
could have done if we knew the initial header parsing wasn't going to
block on us.

with the sigio/siginfo/sigwaitinfo() model I can do the initial parsing of
an insane amount of incoming connections with very very little overhead.
I even get accept() balancing of an arbitrary number of listening sockets
across N of these sigio/siginfo spinning threads basically for free.

but all of that goes out the window if the request parsing could block.
all someone needs to do is hold a port open without sending data and the
whole thread is dead to the world ;)  one could put timeouts and such in,
but the idea of trying to break the protocol code while stuck in read()..
you get the idea :)

And as you quite rightly point out, the vast majority of responses fit in
the tcp send buffers anyway.  If I'm forced to have a thread that can
block on the initial request parsing, it would be silly to have its i/o
fall back to the sigio/blah i/o engine if most of them fit into the send
buffer.

the beauty of the sigio worker model is that you can handle all those
'fast path' request->file connections without the overhead of thread
management, scheduling, etc, etc.

If we can work a way to read in an initial BUFF asyncly and be able to
pass it to a 'verification' mode of the protocol parsing that will return
one of the request 'types' below or throw back an incomplete error, I
think thats all we need to see static serving to through the roof.

> So what we do is we modify the response handlers only.  We teach them
> about how to send async responses.

I'm all for this bit as well :)

> I expect this to be a simple message passing protocol (pass by reference).
> Well rather, that's how I expect to implement it in ASH -- where I'll
> have a single thread per-process doing the select/poll stuff; and the
> other threads are in a pool that handles the protocol stuff.  For your
> stuff you may want to do it another way -- but we'll be using a common

the sigio/siginfo stuff is only really a low overhead nonblocking fd event
engine, same as select()/poll() for most design concerns.  so yeah, I'd
have the initial accepting poll handle the request and pass the async
finisher functions to a bunch of sigio/siginfo threads that deal with
muxing the non blocking responses..

>     struct msg {

might a 

	void *mpm_priv;

be handy?

> The nice thing about this is that these operations are protocol
> independant... at this level there's no knowledge of HTTP, so the same
> MPM core could be used to implement other protocols.

I definitely like that bit.

> You should be able to implement this in your MPM easily I think... because
> you'll see the different message types and can distribute them as needed.

yup, its a simple matter of F_SETOWN in my case :)

-- zach

- - - - - -
007 373 5963


Mime
View raw message