On Fri, Mar 14, 2003 at 05:35:16PM +1100, Peter Jeremy wrote:
> On Thu, Mar 13, 2003 at 06:50:18PM +0200, Enache Adrian wrote:
> >I have no benchmarks, but judging after the way things are implemented
> >in the FreeBSD kernel, select() is definitely faster.
> 
> Can you explain what leads you to make this statement please.

But poll() swaps a _LOT_ more data between the kernel and userland !

> >Please someone explain me what is meant in select(2) by:
> >
> >  If nfds is greater than the number of open files, select() is not guaran-
> >  teed to examine the unused file descriptors.   For historical reasons,
> >  select() will always examine the first 256 descriptors.
> 
> The second sentence appears to be an error.  I can't find anything in
> the current code (or previous versions) that suggests select() would
> ever examine more than nfd FDs.  The only reference to 256 is can find
> is that FD_SETSIZE used to be 256 and select() used to return EINVAL if
> nfd > FD_SETSIZE.

It probably wants to say ( in a manner quite confusing for a non
english speaker like me ) that select(2) won't bother to return EINVAL
for bad file descriptors which are in the bitmaps and are both greater
than the greatest open file descriptor and greater than 255.

That's only half wrong. :-)

select() won't bother to check them even if they are < 256. It's 
only the greatest open file descriptor that matters.

-- from kern/sys_generic.c:751 - kern_select()
        if (nd > td->td_proc->p_fd->fd_nfiles)
                nd = td->td_proc->p_fd->fd_nfiles;   /* forgiving; slightly wrong */
---

Take a look at this little program:
------------------------
#include <sys/select.h>
#include <unistd.h>

int main()
{
        fd_set set;
        FD_ZERO(&set);
        FD_SET(0,&set);
        FD_SET(20,&set);
        if (select(FD_SETSIZE,&set,0,0,0) == -1)
                err(1,"select");
        return 0;
}
------------------------

change 20 to 19 and select() will return EBADF.
Linux will return EBADF even if you put FD_SETSIZE-1 there.

I find FreeBSD's behaviour reasonable - and I wonder what
'historical' programs pass dummy, never opened fds to select()
in the hope of getting EBADF in return.

Regards
Adi

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Reply via email to