too many open file descriptors messages since bind 9.4.2-P1 (port dns94)

[Bakul Shah]

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>
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!