Date: Sun, 17 Jun 2001 15:33:14 -0500 (CDT) From: Jonathan Lemon <jlemon@flugsvamp.com> To: sascha@schumann.cx, hackers@freebsd.org Subject: Re: poll(2)'s arbitrary limit Message-ID: <200106172033.f5HKXEn56198@prism.flugsvamp.com> In-Reply-To: <local.mail.freebsd-hackers/Pine.LNX.4.33.0106172146470.6072-100000@rossini.schumann.cx> References: <local.mail.freebsd-hackers/20010617153129.N1832@superconductor.rush.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <local.mail.freebsd-hackers/Pine.LNX.4.33.0106172146470.6072-100000@rossini.schumann.cx> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200106172033.f5HKXEn56198>