httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Kosut <ako...@organic.com>
Subject Re: filter API spec
Date Wed, 03 Sep 1997 00:59:22 GMT
On Tue, 2 Sep 1997, Dean Gaudet wrote:

[...]

> There is no reason to provide bwritev() at the moment, because nothing at
> the application level above BUFF uses it.  Nothing up there typically
> needs to use it ... they either have a need for fully buffered output
> (i.e. the headers, mod_include, mod_autoindex) or for completely
> unbuffered output (i.e. default_handler, or mod_cgi).  The former
> necessarily involve user-space memory copies because the output is being
> generated on the fly.  The latter two involve mass output of things
> already in memory somewhere ... and it's the latter two cases which cause
> the writev() code in buff.c to go to work. 

Except there can be combinations of the two. Example: includes as a
filter. default_handler does memory mapping, so creates an unbuffered
BUFF, expecting to write out to it directly. Apache, however, has other
plans, and sticks an includes filter on top. Now, what you really want is
for the core default handler, which is sending out nice, big, chunks, to
send data to the include filter in an unbuffered way, but the includes
filter writes data in dribbles, so you want it to be buffered before
sending it to the client.

This is pretty easy to have working, by making sure BUFF options can be
(and are) set by all the involved parties (http_core.c, mod_include.c,
buff.c) in the right places, and to the write (er... I mean right) BUFFs.

[...]

> I want to see chunking implemented as a filter, it would vastly simplify
> the buff.c code.  But with your current proposal we cannot do this without
> either unnecessary memory copying or without extra system calls.

Hmm. The way Ed and I had approached it, we would have kept all the
existing buff.c code for chunking use. But if you want chunking
implemented as a filter at all times...

Well, if the chunking filter sets the BUFF below it (probably the bottom
- the buff.c code which sends to the client) to unbuffered, and calls
bwrite() four times for the peices of the chunk, will the current BUFF
code use writev()? Can it be made to? Maybe we need a bwritev() after all
(which would call writev() if it was the bottom filter, else it would
behave the same as bwrite(), I guess).

I think that could work. Obviously, this is why people use prepackaged
libraries like sfio; they've already figured this stuff out.

-- Alexei Kosut <akosut@organic.com>


Mime
View raw message