On Jul 07, Bill Sommerfeld wrote:
| > ah yes, this explains it, thanks.
| > i have holes in the set of file descriptors i pass to poll(),
| > so while i have more than 20 elements in the set, the highest
| > fd i have is only 11.
| 
| While the check in question is clearly buggy, simply removing the
| check isn't the right answer -- there needs to be some limit on the
| number of poll array elements because the kernel allocates a chunk of
| kernel memory to cover them; if the size is unlimited, the user can
| ask the kernel to allocate essentially arbitrary amounts of kernel
| memory.
| 
| But how do we determine what's a reasonable limit?

the maximum number of open files seems like a good place to
start, and probably is a better choice than the current
simplistic check.
this would also work for me since this is how i size the set
i pass to poll() in the first place.

yes, i could rewrite the code to have a dense set of struct
pollfd, but the reason i didn't do it in the first place was
to make the code simpler/shorter/more readable/..

This whole thing got me worried and i just tested the limits
on FreeBSD, Solaris, and Linux.  The first two limit the size
to the maximum number of open files, while Linux doesn't seem
to have any limit.