Re: Possible problem with zero-copy TCP and sendfile()

Jesse S Sipprell
2001-04-17T20:44:42Z

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