On Tue, Apr 17, 2001 at 01:23:07PM -0700, David S. Miller wrote:
> One more subtle note, for the case of error handling. There is a
> change to sendfile() in the zerocopy patches which causes sendfile()
> to act more like sendmsg() when errors occur.
How is this likely to affect applications?
Currently, the glibc2.1 sendfile interface looks like:
ssize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count);
On error, -1 is returned in the usual fashion and offset is purported to be
updated to point to the next byte following the last one sent.
Will the zerocopy patches break this?
>
> Specifically, sendmsg() works roughly like the following when an
> error happens:
>
> handle_error:
> if (sent_something)
> return how_much_we_sent;
> else
> return ERROR_CODE;
>
> So when an error happens, and the kernel was able to send some of
> the data, you see something like this in the trace:
>
> sendmsg() = N
> ...
> sendmsg() = ERROR_CODE
>
> sendfile() used to act differently, and this made it difficult to
> directly transform a sendmsg()+local_buffer based server into a
> sendfile() one because the error handling was so different.
>
> Previously, sendfile() wouldn't give you the partial transfer length,
> you'd just get the error _regardless_ of whether any data was sent
> successfully during that call. Alexey, myself, and others considered
> this behavior bogus and inconsistent. So it was changed.
>
> The long and short of it is that sendfile() now acts just like
> sendmsg() when errors happen mid-send.
>
> Later,
> David S. Miller
> davem@redhat.com
-- "In the event of a failure, the system can be configured to automatically restart itself. This feature of Windows NT Server provides maximum system up-time." -- Reliability and Fault Tolerance in Windows NT Server, MSC - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Apr 23 2001 - 21:00:24 EST