--1ccMZA6j1vT5UqiK
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Apr 02, 2004 at 12:43:00PM -0500, der Mouse wrote:
> > i think it's beyond time netbsd increased the default fd's per
> > process.  i'd like to make a change along these lines, but first i'd
> > like to collect some input on: [...]
>=20
> I'd also recommend changing the default FD_SETSIZE value, especially if
> you raise the default fd limit as high as 256.

We can't. At least not blindly.

The problem is we have library code that assumes what FD_SETSIZE is. I=20
think it's the Sun RPC code. Since the size of the set isn't passed in, if=
=20
we just up FD_SETSIZE in libc, then we break older programs. If we don't=20
up FD_SETSIZE, then a program that makes use of the larger set size (and=20
thus more fd's) can run into issues.

Hmmm... With libc symbol versioning, we might be able to work something=20
out...

> Yes, userland _can_ define FD_SETSIZE higher before #includes, but
> generally doesn't.  I had to help debug a peculiar problem recently
> that ended up being code using select and fd_sets but not checking that
> file descriptors were < FD_SETSIZE.  Guess what happens when you
> allocate an fd_set on the stack and then use FD_SET/FD_CLR with file
> descriptors over FD_SETSIZE with it!

Kaboom! And it's even worse if it's libc that does it. :-)

> Yes, such code is arguably broken.  But the reality is it's out there
> (php on a webserver in the case I dealt with, not some bit of esoterica
> with a userbase you can count on one hand.  This is a problem poll()
> lacks; such experiences are leading me to a "select() delenda est"
> stance, even despite the code complication poll() produces IME.)

Use kevent(). It 1) scales very well, and 2) is much nicer.

Take care,

Bill

--1ccMZA6j1vT5UqiK
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFAbbboWz+3JHUci9cRAujyAJwJSVp3aD4S8duTJ/xyDCvpVluOxACeNSej
LJUks+eXSdQP8G5CmSNuuu4=
=EHba
-----END PGP SIGNATURE-----

--1ccMZA6j1vT5UqiK--