Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Date: Mon, 24 Jul 2000 22:41:10 +0000
From: Tony Finch <dot@dotat.at>
To: new-httpd@apache.org
Subject: Re: Anywhere to go for a summmary of I/O filtering?
Message-ID: <20000724224110.C318@hand.dotat.at>
References: <Pine.LNX.4.21.0007241034470.21368-100000@koj.rkbloom.net>
 <000101bff59b$439aaed0$345985d0@corecomm.net>
 <20000724115959.R10898@lyra.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <20000724115959.R10898@lyra.org>
Organization: Covalent Technologies, Inc

Greg Stein <gstein@lyra.org> wrote:
>
>It is a complete red herring to focus on how async will impact the
>filter design. Async will impact how modules are written, how filters
>are written, and how the overall server is designed.

Actually, I don't think that is necessarily true. I've been thinking
along the lines of creating a clearer response abstraction that
bundles up the metadata (essentially the headers) and the content (a
bucket brigade). In the complicated case the content will be consumed
as it is constructed, but for event-driven IO we're more interested in
the simple case.

One observation is that sometimes we want some data from the previous
request to hang around after the handler has finished in order to put
it into the same packet as the beginning of the response to the next
pipelined connection. For event-driven IO *most* of the response is
held back so that it can be passed to the select() thread.

So: The response handler's job is to put together a bucket brigade
which it does mostly by adding buckets to the end of an existing
brigade and passing them down to the filters which will mangle them in
interesting ways, eventually pulling buckets off the front of the
brigade and sending the contents to the network. At the end of request
handling there will be a brigade containing just the tail-end of the
response. The handler can return the brigade to the core which can
decide whether to flush it now or keep it (hanging off the connection
rec?) so that it can be sent with the start of the responce to the
next pipelined request.

In the simple case the bottom-level filter code can notice that the
brigade is just FILE, EOS and decide that it'll do nothing (except
perhaps mark it as being simple) and let the whole thing be returned
to the core by the handler. The core can then spot the simple brigade
and pass it aside to the select() thread.

Thus you can get event-driven IO in many cases without having to write
event-driven response handlers. The crucial thing is to have a
reasonably powerful abstraction for responses, which does *not* mean
it is really complicated.

(... Further in the future you can allow response handlers to return
a brigade to the core that doesn't have an EOS marker, and the core
will know that it should call the handler again to get more data. This
gives you a simple migration towards fully event-driven response
generation. ...)

Tony.
-- 
f.a.n.finch    fanf@covalent.net    dot@dotat.at
478 fruit-flavored floor wax