Date: Tue, 4 Mar 2003 21:42:18 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Terry Lambert <tlambert2@mindspring.com> Cc: Sean Chittenden <sean@chittenden.org>, Hiten Pandya <hiten@unixdaemons.com>, <arch@FreeBSD.ORG>, <dwmalone@FreeBSD.ORG> Subject: Re: Should sendfile() to return ENOBUFS? Message-ID: <20030304210901.L37414-100000@gamplex.bde.org> In-Reply-To: <3E641131.431A0BA8@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 3 Mar 2003, Terry Lambert wrote: > sendfile: > > When using a socket marked for non-blocking I/O, sendfile() may send > fewer bytes than requested. In this case, the number of bytes success- > fully written is returned in *sbytes (if specified), and the error EAGAIN > is returned. > > This seems to indicate several things: > > 1) The correct error is EAGAIN, *not* ENOBUFS I agree. There seem to be more bugs near here: - sendfile(9) can return ENOBUFS for some other resource shortages, but this is undocumented for sendfile(2). - the wait can now be terminated by an signal. Then sendfile(9) returns the undocumented error EINTR. - sendfile(9) is never restarted after it is terminated by an signal. I don't know if it can be, but restarting is easier for applications to deal with so it should be done if possible. - sendfile(2) has a better way of reporting short counts than write(2). This seems to work for all types of errors, but this is only documented to work for EAGAIN errors. > 2) You need to be damn sure you can guarantee a correct update > of *sbytes; I believe this is very difficult in the case in > question, which is why it blocks No, since it just waits for a buffer and knows how much it already sent. > 3) If sbytes is NULL, you should probably block, even on a > non-blocking call. The reason for this is that there is > no way for the application to restart without *sbytes No, since a NULL sbytes means that the application doesn't care how many bytes got sent if there was an error. Such applications already don't handle other types of error. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030304210901.L37414-100000>