httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "RobS" <r...@ipass.net>
Subject RE: errnos and buff.c
Date Sat, 19 Dec 1998 19:59:33 GMT
> Just how would it memcpy?  The buffer empties from the bottom, and fills
> at the top.  We've already decided it was full.  If we've had a partial
> write then we've got space at the bottom, not the top.

You'd have to move whats left in BUF down (unless the buffer was circular)
and then copy from buf.  It just seems silly to force another call to
write() to ship the last <small number> bytes in BUFF so you can copy in the
<small number> bytes (left) in buf to a clean BUF.

I don't know how often partial writes typically occur (slow clients) for 4K.
I just assumed that they do - its not something we have control over.

> If this case occurs in practice then yeah we may want to optimize it.  I'm
> not convinced it occurs frequently enough to be worth it (or I'm not
> understanding your explanation).

The writev case goes further, it'll never leave data in BUF if the bwrite()s
are longer than LARGE_WRITE_THRESHOLD.  The call to writev_it_all() from
large_write() forces a complete write of not only all of BUF, but all of buf
as well.  When writev() is available, every call to bwrite() longer than 31
bytes will result in its own call to writev() (or more than one if need be),
i.e. no buffering (at the application layer).  This is the case even when
not chunking.  When writev() is not available on the platform, buffering
occurs as expected.

It doesn't appear to me to be much of an effort, but maybe I'm just missing
something.

  robs


Mime
View raw message