Date: Tue, 4 Mar 2003 13:03:38 +0300 (MSK) From: Igor Sysoev <is@rambler-co.ru> To: Sean Chittenden <seanc@FreeBSD.ORG> Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Should sendfile() to return ENOBUFS? Message-ID: <Pine.BSF.4.21.0303041234500.78388-100000@is> In-Reply-To: <20030303224418.GU79234@perrin.int.nxad.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 3 Mar 2003, Sean Chittenden wrote: > I've got a cluster of busy servers and have now exhausted the number > of sf_buf's available. top(1) reports that applications using > sendfile(2) are spending quite a bit of time in the 'sfbufa' state > blocking even though the socket is non-blocking. I'd consider this a > pretty nice bug and that sendfile(2) should return ENOBUFS instead of > blocking on a non-blocking call. Right now if sf_buf_alloc() returns > NULL, it is assumed that the call was sent a signal and was > interrupted. So I have a two fold question: > > 1) Should sendfile(2) block on a non-blocking socket when there are no > sf_buf's available? > > I don't think it should. sendfile(2) should return ENOBUFS and let > the user land process continue working even though the kernel is > constrained for sf_buf's. > > 2) Will changing the sendfile() call to return ENOBUFs break source > compatibility across sendfile() implementations? sendfile() can block on a non-blocking socket at least in two cases: 1) sf_buf's exhaustion (as you have described), 2) and reading file page from the disk. In these cases we could return: 1) EAGAIN for both cases, 2) or ENOBUFS for sf_buf's exhaustion and EAGAIN (or new special error) for reading file page (after initiating disk transfer of course). ENOBUFS (and new special error) could be enabled via sendfile() flag parameter, which currently unused and should be zero, so we would not break source and even binary compatibility. But there is the one problem - how to notify user-level code about readiness of these events, especially with EAGAIN ? select()/poll()/kevent() (or kevent() only) should check not only socket reasiness but readiness of the read operation (if it was initiated) and free sf_buf's (if we exhausted them last time). Igor Sysoev http://sysoev.ru 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.0303041234500.78388-100000>