httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject mpm buff
Date Wed, 23 Jun 1999 19:33:15 GMT
I'm still hacking on buff... but between work and a weekend in the hills I
probably won't commit anything new until next week. 

The real stumbling block is handling chunked and non-blocking at the same
time -- which I want for the case of async copying dynamic responses from
another process (CGI, fastCGI, mod_jserv, ...).  There's a bunch of
special cases where a partial write happens in the middle of the chunk
header/trailer. 

My current approach is to always write the chunk header and trailer into
the BUFF's buffer.  When I get a partial write I keep track of how many
bytes I've committed to in this chunk.  i.e. if I said the chunk was
0x1000 bytes but only manage to write 0x800 then I'll remember that I have
to write another 0x800 bytes before starting another chunk.  This has to
be stuck in the BUFF structure because in the async case we have to return
from bwrite after the partial write. 

I'll end up with an improvement on 1.3... 1.3 will generate 4 element
writevs which look like this:

iov[0] -- the output buffer from BUFF
iov[1] -- a small chunk length buffer
iov[2] -- a large write buffer passed to bwrite(), say 4k or 32k
iov[3] -- "\r\n"

For 2.0 I'm combining iov[0] and iov[1], and then placing the "\r\n" into
the BUFF buffer rather than sending it out as part of the writev... where
it'll be combined with the next bwrite(), or sent out in a bflush(). 

You might wonder -- won't this cause a write() of 2 bytes sometimes?  Yeah
I think it will.  But I have an idea for that.  Either way I don't think
it'll cause 2 byte packets to go out -- because I suspect in most cases
it'll just end up in the socket output buffer because we'll have stuffed
the buffer full prior to sending the final \r\n.

Dean



Mime
View raw message