Date: Mon, 10 Mar 2003 10:33:52 +0300 (MSK) From: Igor Sysoev <is@rambler-co.ru> To: Sean Chittenden <sean@chittenden.org> Cc: arch@FreeBSD.ORG Subject: Re: Should sendfile() to return EAGAIN? [patch] Message-ID: <Pine.BSF.4.21.0303101033300.86097-100000@is> In-Reply-To: <20030309214638.GN79234@perrin.int.nxad.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 9 Mar 2003, Sean Chittenden wrote: >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:: If you protect ENOBUFS with SF_ENOBUFS flag then you do not break any source and binary compatibility. All current apllication should call sendfile() with zero flag so they will never get ENOBUFS. Yes, of course they will still block when sf_buf's would exhausted. But current application has no knowledge about sf_buf's exausting and has no ways to workaround it. If they will get EAGAIN on this condition then they will simply eat CPU cycles polling sendfile(). The applcation that knows about ENOBUFS and has the code to workaround it can pass SF_ENOBUFS flag to sendfile(). >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). Monitoring is the good thing but if you want to preserve the compatibility and add the non-blocking behaviour to current applicaiton then it's much better to bind select()/etc with sf_buf's freeing - it would be the transparent change to the applications. Igor Sysoev http://sysoev.ru/en/ 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?Pine.BSF.4.21.0303101033300.86097-100000>