too many open file descriptors messages since bind 9.4.2-P1
bakul at bitblocks.com
Wed Jul 16 07:19:26 UTC 2008
On Tue, 15 Jul 2008 16:37:00 PDT JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <Jinmei_Tatuya at isc.org> 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 <julian at elischer.org> 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 <peterjeremy at optushome.com.au>
> 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!
More information about the freebsd-net