From owner-freebsd-hackers Sun Jun 17 13:33:55 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 50AB337B401 for ; Sun, 17 Jun 2001 13:33:50 -0700 (PDT) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id f5HKXEn56198; Sun, 17 Jun 2001 15:33:14 -0500 (CDT) (envelope-from jlemon) Date: Sun, 17 Jun 2001 15:33:14 -0500 (CDT) From: Jonathan Lemon Message-Id: <200106172033.f5HKXEn56198@prism.flugsvamp.com> To: sascha@schumann.cx, hackers@freebsd.org Subject: Re: poll(2)'s arbitrary limit X-Newsgroups: local.mail.freebsd-hackers In-Reply-To: References: Organization: Cc: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In article you write: >> You've misinterpreted the paper. :( > > Sorry, I got the reference wrong. I was referring to a > recently published HP paper[1] which concluded that "contrary > to conventional wisdom, even a select based server can > provide high throughput if its overhead is amortized by > performing more useful work per select call." > > This supported the results of benchmarks I conducted on > FreeBSD using select, poll and kqueue at the heart of the > State Threads implementation. > > [1] http://www.hpl.hp.com/techreports/2000/HPL-2000-174.pdf Well, I have to disagree, as the conclusion in the above paper is misleading. Basically, they say that if a listen socket returned by select() becomes ready, then it is more efficient to call accept() on the socket multiple times, rather than once per select() call. Well gee, that's nice, and quite true, but has nothing to do with the efficiency (or lack thereof) of select() itself. This is simply the old 'polling' vs 'interrupt' argument that has been around for ages (see also: 'interrupt livelock'). -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message