> 
> Well, it could be written like:
> 
> 	int len=0;
> 	struct pollfd pfd[MAXFDS]; 
                          ^^^^^^  How do you know what this is....
> 
> 	if (myfd1) {
+++++		pfd[len].fd = myfd1;
> 		pfd[len].events = ...;
> 		pfd[len].revents = ...;
> 		len++;
> 	}
> 
> 	if (myfd2) {
> 		...

It is much more usual to set pfd[fd].fd = fd which simplifies
the user side and is ok unless you have are polling for fd #1000
(and no others).
> 
> Readable and doesn't waste kernel memory.
Just user space code bloat....

> 
> > 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.
> 
> Upping the limit to maximum number of open files would prolly be sensible.
> However, I personally don't see a problem in keeping it the way it is
> (and documenting the behaviour).

The SuS says that EINVAL should be returned if the 'nfds' argument
is greater than OPEN_MAX.

This would be p->p_rlimit[RLIMIT_NOFILE].rlim_cur instead of
p->p_fd->fd_nfiles.

(There should be a check in setrlimit to ensure that
p->p_rlimit[RLIMIT_NOFILE].rlim_cur > p->p_fd->fd_lastfile)

The limits.h page says the OPEN_MAX is a compile-time limit, and the
run-time one can be found using sysconf().
sysconf() says that the values it returns should be constant for the
lifetime of a process.
setrlimit(RLIMIT_NOFILE,...) allows a process to change the value
- which breaks the sysconf() interface rules.
Nice and consistent!

	David

-- 
David Laight: david@l8s.co.uk