httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject RE: errnos and buff.c
Date Fri, 18 Dec 1998 22:53:21 GMT

On Wed, 16 Dec 1998, RobS wrote:

> While buff.c is under discussion, I had some questions..
> - Shouldn't BUFF be circular, at least for platforms that support writev()?

I don't really see the point... I don't think we get partial writes
frequently enough to warrant the complexity.  But if you want to
instrument a server and figure out how frequently we do byte shuffle due
to partial write... that'd be cool to know.  It might only show up for
long haul slow modem links. 

> - Why does bwrite() generally cause the BUFF to be emptied (e.g. even when
> one write() might suffice to move the contents of buf into fb and
> !chunking)?  The current approach can mean more total calls to write() and
> more byte shifting.


>> - Although I realize bwrite()'s interface calls for handling all of buf, I'd
> like to have a "conventional" write() interface that supports partial writes
> (like write_with_errors, but at the bwrite layer) so I don't have to wait on
> anymore IO than is necessary.  I can certainly roll my own, but I would
> think this would have some general appeal.  At any rate, exposing
> ap_write(), write_with_errors(), and buff_write() would be helpful.

Yeah, and you're going to do all the chunking yourself?  No, this won't
happen until chunking can become a layer. 

> - Allowing the BUF to be sized when created would make these routines more
> useful outside the core.  I can reallocate inbase and outbase, but this will
> mean tossing 8K of memory unnecessarily.

I question why this is useful. 

> - buff.h suggests putting pointers to the basic I/O routines here in the
> BUFF struct.  I think this too would make BUFF more useful outside the core.
> I'd especially like to see start_chunk() and end_chunk() be a BUFF data
> member (CHUNK_HEADER_SIZE would have to be as well).

Anything to do with chunking is an artifact of not having i/o layering.
We're not going to export it any more than it already is.


View raw message