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

[Jesse S Sipprell <jss@inflicted.net>]

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