Date: Sun, 4 Jul 1999 17:51:06 -0500 From: Jonathan Lemon <jlemon@americantv.com> To: Mike Smith <mike@smith.net.au> Cc: hackers@freebsd.org, zach@zabbo.net Subject: Re: poll() scalability Message-ID: <19990704175106.56355@right.PCS> In-Reply-To: <199907042037.NAA07661@dingo.cdrom.com>; from Mike Smith on Jul 07, 1999 at 01:37:13PM -0700 References: <19990704000042.59954@right.PCS> <199907042037.NAA07661@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jul 07, 1999 at 01:37:13PM -0700, Mike Smith wrote: > > I'd like to open discussion on adding a new interface to FreeBSD, > > specifically, a variant of poll(). > > > > The problem is that poll() (and select(), as well) do not scale > > well as the number of open file descriptors increases. When there > > are a large number of descriptors under consideration, poll() takes > > an inordinate amount of time. For the purposes of my particular > > application, "large" translates into roughly 40K descriptors. > > > > As having to walk this descriptor list (and pass it between user and > > kernel space) is unpalatable, I would like to have the interface > > simply take a "change" list instead. The kernel would keep the > > state of the descriptors being examined, and would in turn, return > > a short list of descriptors that actually had any activity. > > Zach Brown (copied) had some interesting ideas about this sort of thing > that he was very happy to espose while we were wandering around ZD a > few weeks back. I'm rather enamoured of anything that effectively > works like a callback mechanism (eg. signal delivery on an alternate > stack) as it scales far better to a threaded application. I would think that a system that uses callbacks (like POSIX's completion signals) would be more expensive than a call like poll() or select(). Also, you really want to return more than one event at at time in order to amortize the cost of the system call over several events, this doesn't seem possible with callbacks (or upcalls). Also, I would guess that you would start getting into locking problems, and how to cancel a signal which has already been posted. -- 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?19990704175106.56355>