Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 14 Oct 1995 19:14:32 -0700 (MST)
From:      Terry Lambert <terry@lambert.org>
To:        bde@zeta.org.au (Bruce Evans)
Cc:        hackers@freefall.freebsd.org, rdm@ic.net, current@freefall.freebsd.org
Subject:   Re: getdtablesize() broken?
Message-ID:  <199510150214.TAA22230@phaeton.artisoft.com>
In-Reply-To: <199510142307.JAA28668@godzilla.zeta.org.au> from "Bruce Evans" at Oct 15, 95 09:07:58 am

next in thread | previous in thread | raw e-mail | index | archive | help
> >I was messing around with a program that calls select() - for some reason I
> >kept getting EINVAL. So I twiddled with the sources a bit, and found that
> >giving 64 as the first argument to select() (rather than getdtablesize())
> >fixed the error. Is this a problem with one of the two functions? The
> >program is known to work on many other systems, and it did for me when I
> >was using FreeBSD 2.0, so I don't think it is the problem. (BTW, I'm using
> >2.2-current now.)
> 
> If you've used the bogus (non-)option OPEN_MAX in your kernel config and
> made it > 256, then select() could quite easily break like that.  select()
> can't handle more than 256 file descriptors.
> 
> Using getdtablesize() as the count arg to select() is wrong anyway.  It
> may specify more bits than are in the fd_set struct.  It tells the kernel
> to look at a huge number of fd's but the fd's of interest may all be
> small, smaller than the fd of the largest open file.  The kernel actually
> truncates the count to 1 plus the largest open fd.  It considers this as
> `forgiving, slightly wrong'.  For some reason (perhaps to trap misuse of
> getdtablesize()), it considers counts > 256 as an error before forgiving.

The actual number you are supposed to use is the highest open fd in the
select() clause's bit representation.

By using 64, you are considering a bit vector that is also potentially
larger than it should be.

The correct limit on the largest number is FD_SETSIZE, as defined in
sys/types.h.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510150214.TAA22230>