From owner-freebsd-arch Mon Mar 10 0:50:17 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 67BD137B401 for ; Mon, 10 Mar 2003 00:50:15 -0800 (PST) Received: from park.rambler.ru (park.rambler.ru [81.19.64.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E24F43FBF for ; Mon, 10 Mar 2003 00:50:13 -0800 (PST) (envelope-from is@rambler-co.ru) Received: from is.park.rambler.ru (is.park.rambler.ru [81.19.64.102]) by park.rambler.ru (8.12.6/8.12.6) with ESMTP id h2A8o7mF052825; Mon, 10 Mar 2003 11:50:07 +0300 (MSK) Date: Mon, 10 Mar 2003 11:50:07 +0300 (MSK) From: Igor Sysoev X-Sender: is@is To: Peter Jeremy Cc: arch@FreeBSD.ORG Subject: Re: Should sendfile() to return EAGAIN? [patch] In-Reply-To: <20030310072318.GA3343@cirb503493.alcatel.com.au> Message-ID: 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, 10 Mar 2003, Peter Jeremy wrote: > Looking at FreeBSD, the only standard application that uses sendfile(2) > is ftpd(8) - and it doesn't care what the actual errno is. The libc_r > wrapper would need to be modified though and there may be ports that > use sendfile(2). ftpd(8) will not get ENOBUFS because it uses the blocking sockets. libc_r wrapper and sendfile() patch in the thttpd port are under the control so it can be modified to use SF_ENOBUFS flag and to understand ENOBUFS condition. But I think there are many in-house high perfomance solutions that use kqueue() and sendfile(). If they handle too many simultaneous slow connections with sendfile() then after FreeBSD upgrade they start to eat CPU without any visible reasons (in EAGAIN case) or will broke (in ENOBUFS case). > > 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:: > > The descriptions of the errors (from intro(2)) are: > 35 EAGAIN Resource temporarily unavailable. This is a temporary condi- > tion and later calls to the same routine may complete normally. > 55 ENOBUFS No buffer space available. An operation on a socket or pipe > was not performed because the system lacked sufficient buffer > space or because a queue was full. > > Whilst both errors cover the situation, "ENOBUFS" provides more > information to the caller and I would therefore consider it as the > preferred error. Yes, ENOBUFS is the good candidate but it should be enabled via flag. Igor Sysoev http://sysoev.ru/en/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message