From owner-freebsd-arch Sun Mar 9 13:47: 7 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 DD54937B409 for ; Sun, 9 Mar 2003 13:47:05 -0800 (PST) Received: from perrin.int.nxad.com (internal.ext.nxad.com [69.1.70.251]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B36243F3F for ; Sun, 9 Mar 2003 13:47:05 -0800 (PST) (envelope-from sean@perrin.int.nxad.com) Received: by perrin.int.nxad.com (Postfix, from userid 1001) id 8CEE42105E; Sun, 9 Mar 2003 13:46:38 -0800 (PST) Date: Sun, 9 Mar 2003 13:46:38 -0800 From: Sean Chittenden To: Igor Sysoev Cc: arch@FreeBSD.ORG Subject: Re: Should sendfile() to return EAGAIN? [patch] Message-ID: <20030309214638.GN79234@perrin.int.nxad.com> References: <20030309135037.GK79234@perrin.int.nxad.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-PGP-Key: finger seanc@FreeBSD.org X-PGP-Fingerprint: 3849 3760 1AFE 7B17 11A0 83A6 DD99 E31F BC84 B341 X-Web-Homepage: http://sean.chittenden.org/ 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 > >The patch updates the case of sendfile() when there aren't any > >sf_buf's available. Instead of calling msleep() and blocking the > >caller on a socket that has been marked non-blocking, return > >instantly with EAGAIN. This doesn't provide a mechanism for > >identifying that there aren't any sf_buf's available. At some > >point a read only sysctl > > I think if this sendfile() behaviour will be implemented it should > return ENOBUFS and should be explicity enabled by the application > via sendfile() flag (something like SF_ENOBUFS). > > EAGAIN should be returned only if there is some way to notify the > application about the operation readiness via > select()/poll()/kevent(). Eh, well, I vacillate on this topic, but there is something to be said for source compatibility. Using EAGAIN requires no changes to existing code. Returning ENOBUFS does require a change to existing code. Since the cat's five years out of the bag, I'm not too thrilled about the possibility of breaking existing apps by changing the behavior of a syscall. By the same token, it seems more correct to me to signify to the app that the OS is maxed (ENOBUFS) as opposed to the client being maxed (EAGAIN). ::shrug:: I lean on the side of preserving src level logic compatibility along with adding the ability to monitor the number of sf_buf's in use, free, and the max number of sf_buf's used (akin to mbuf's usage). -sc -- Sean Chittenden To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message