On Mon, 3 Jul 2000, Jonathan Stone wrote:

: >> FD_SETSIZE is currently 256. Is there a good reason not to bump it to
: >> something more appropriate for today's machines, like 1024 or 2048?

Yes.  That means that FD_ZERO takes four to eight times as long, and fd_set
copies perhaps more.  That's a bigger penalty than you may think in
applications such as a proxy, especially on slower architectures.

Most applications don't have >256 open files; in fact, you have to raise the
rlimits just to allow that.  Why inflict a penalty by default?

: >> So it has a big potential payback for those who want it, at
: >> relatively little cost. 

If you need more, the standards already tell you how to do so.  #define
FD_SETSIZE to whatever your application desires before including
anything.  It's that simple.

: FWIW, Linux ships with FD_SETSIZE = 1024 and has done for years.

Linux doesn't have a vax port, and hasn't for years.  (This comment is
intended to point out that a 32-byte copy is much less expensive on some
slower architectures--that NetBSD supports--than a 128-byte or 256-byte
copy, which is what a larger default FD_SETSIZE would imply.)

-- 
-- Todd Vierling (tv@pobox.com)