On Tue, 15 Jul 2008 16:37:00 PDT JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <[EMAIL PROTECTED]> wrote: > > Perhaps You're probably confused poll(2) with /dev/poll. The latter > behaves as you described (but is not portable as poll(2)).
Indeed I am confused. Not sure where I got that idea. On Tue, 15 Jul 2008 16:17:04 PDT Julian Elischer <[EMAIL PROTECTED]> wrote: > Bakul Shah wrote: > > ... > > Presumably kqueue has a lower cpu usage until the system gets > > loaded at which point polling might win. > > I don't think so, since kqueue only runs code associated with events > that have actually happened, and then only once until it's processed > where las I looked poll had more to do on each call. Yes. poll/select overhead of scanning the entire list is incurred on each system call + the kernel overhead (as Alfred pointed out later). On Wed, 16 Jul 2008 09:42:54 +1000 Peter Jeremy <[EMAIL PROTECTED]> wrote: > Note that, based on sys_generic.c in 7.x and -CURRENT, poll(2) is > limited to checking FD_SETSIZE descriptors, whilst select(2) has > no upper limit. I strike out here as well. I should've read the code much more carefully or tested select() before opening my mouth. All in all it was not a good idea to post anything. My apologies for wasting everyone's time. And thanks all for correcting me without any flaming! _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
