David Laight wrote:
> You will find that the cost of that code section is irrelevant
> provided the supplied array isn't stupidly spare.

mumble mumble ... cost of memory-to-memory copy ... mumble mumble

Seriously - if the array is big enough (doesn't matter if sparse
or not), the memory copy of poll array from userland to kernel
space does take majority of time spent in poll(2) call. This is
the one of reasons why kqueue was implemented, and why e.g. Sun
/dev/poll exists.

> RTFM, it is a 'variable' constant and the run time value can
> be different from the compile time one.
> sysconf( _SC_OPEN_MAX ) could even return -1 implying that there
> is no appropriate limit.  After all setrlimit() could increase
> it indefinitely.

OPEN_MAX is compile time constant. sysconf(_SC_OPEN_MAX) is different
story :) If you reference OPEN_MAX in your code, you get '64' currently
always - see <sys/syslimits.h>.
 
> Erm, both netbsd and the SuS have:
>      The setrlimit() function may fail if:

> This would be useful because it would let a program determine
> a (sensible) upper bound for the highest open fd.
> This is a number that certain processes need to know (eg in order
> to close all high numbered fds) but is impossible to determine.
> Typically rlimit(NO_FILES) is used - causing a lot of failed close()
> calls if it is set very high.

Note 'may' above. It's not 'shall' neither 'must'.

Is it really true that close() returns error for the high-numbered
fds once you lower rlimit(NOFILES)? I seriously doubt that.  If
this is true, it's a bug and should be fixed - can you send-pr it,
please?

I personally don't see usefullness of such feature in context
you cite.

Jaromir 
-- 
Jaromir Dolecek <jdolecek@NetBSD.org> http://www.NetBSD.org/Ports/i386/ps2.html
-=- We should be mindful of the potential goal, but as the tantric    -=-
-=- Buddhist masters say, ``You may notice during meditation that you -=-
-=- sometimes levitate or glow.   Do not let this distract you.''     -=-