From owner-freebsd-arch Tue Mar 4 2:40:42 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D95137B401; Tue, 4 Mar 2003 02:40:41 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id D00A443FDF; Tue, 4 Mar 2003 02:40:39 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id VAA31947; Tue, 4 Mar 2003 21:40:26 +1100 Date: Tue, 4 Mar 2003 21:42:18 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Terry Lambert Cc: Sean Chittenden , Hiten Pandya , , Subject: Re: Should sendfile() to return ENOBUFS? In-Reply-To: <3E641131.431A0BA8@mindspring.com> Message-ID: <20030304210901.L37414-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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