apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: [PATCH] apr_file_writev() on UNIX
Date Wed, 06 Oct 2004 17:01:24 GMT
At 11:12 AM 10/6/2004, you wrote:
> 
>As far as not having a bug in the !HAS_WRITEV implementation,
>I disagree.
>The current implementation does not have a single chance of
>being successful if there is more than 1 vector. This does
>not make sense to me. Let assume the write part is successful,
>the function will return apr_success but has completely failed
>to his task.

That's only partially true - we should never return for a blocking
socket writev, only for a nonblocking one when the socket would
block on the remaining vector(s).

>In the header file there is a remark saying that apr_file_writev
>is available even if the underlying os doesn't provide writev().
>Why providing something that it is going to fail every single
>time?

Does writev() return *success* on a partial-write?  I very much
doubt it (EINTR, EWOULDBLOCK or EAGAIN is what I would expect.)

The performance of the existing code is obviously sub-par, and we
should loop through all the vectors until we get a hiccup.  At that
point the user can retry the remaining vectors.

I should make a point that it seems 'wrong' we implemented this
lie - there is another property of writev() that we've ignored...

writev() will gather up the vectors into a single datagram, even
when nagle is off.  So this implementation leaves us potentially
sending dozens of datagrams for a few dozen very small buffers.

It seems a true implementation would use it's own buffer to concat
all of the smaller fragments into a single packet - the pain in
cpu is nominal compared to the pain of multiple datagram processing.

Bill


Mime
View raw message