Date: Sun, 9 Mar 2003 13:46:38 -0800 From: Sean Chittenden <sean@chittenden.org> To: Igor Sysoev <is@rambler-co.ru> Cc: arch@FreeBSD.ORG Subject: Re: Should sendfile() to return EAGAIN? [patch] Message-ID: <20030309214638.GN79234@perrin.int.nxad.com> In-Reply-To: <Pine.BSF.4.21.0303092026380.85235-100000@is> References: <20030309135037.GK79234@perrin.int.nxad.com> <Pine.BSF.4.21.0303092026380.85235-100000@is>
next in thread | previous in thread | raw e-mail | index | archive | help
> >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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030309214638.GN79234>