From owner-freebsd-hackers Sat Jul 3 22:41:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 98CAB14D00 for ; Sat, 3 Jul 1999 22:41:55 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id BAA47575; Sun, 4 Jul 1999 01:41:47 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Sun, 4 Jul 1999 01:41:46 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Peter Wemm Cc: "Brian F. Feldman" , Jonathan Lemon , wayne@crb-web.com, hackers@FreeBSD.org Subject: Re: poll() vs select() In-Reply-To: <19990704040435.35CD464@overcee.netplex.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 4 Jul 1999, Peter Wemm wrote: > "Brian F. Feldman" wrote: > > On Fri, 2 Jul 1999, Jonathan Lemon wrote: > > > > > In article 0000@crb.crb-web.com> you write: > > > >now supports the select() and poll() system calls. My question is really > one > > > >of usage. Why would one us poll() over select()? Is select eventually go > ing > > > >to go away for some reason? > > > > > > select() as a user-level call will never go away; there is a large base > > > of code that uses it. > > > > > > poll() is faster (it doesn't have to do bit twiddling), and it's interface > > > is cleaner (it can report invalid fd's, something select() can't do). As > > > its functionality is a superset of select()'s, it is used as the internal > > > implementation for select(). > > > > Actually, select() doesn't require horrendous amounts of copyin()s, which > > poll() does. So have you benchmarked the two? I'd expect select to be faster. > > Actually.. select() has three copyins and three copyouts per call. poll() > has one copyin and one copyout per call. > But poll() copies in HUGE amounts of data compared to the few bytes for thousands of FDs that select does. > Now what I particular like is the event queue system that David Filo put > together for Yahoo. In a nutshell you create a queue (a fd), and then > register the descriptors you want to monitor with the queue. You then run > an accept()-like loop where the accept returns the fd number that has met > the conditions you asked for. For example, if you wanted to know if fd > number 4251 becomes readable, then the accept would return 4251. This has > potential to work across multiple processes sharing a queue so that events > could get round robined or whatever. The other good part is that it > maintains the state and lists persistantly and doesn't have to keep copying > it to/from the kernel. It handles 50,000 to 100,000 connections without > too much trouble. You can still use this with select as the queue fd > becomes readable when there is an event waiting for your process. > > Is there interest in doing something like this in general? Yes! That would not replace select() or poll(), but it would be awesome to have! > > Cheers, > -Peter > -- > Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message