Subject: Re: increasing FD_SETSIZE to 1024 or 2048?
To: Jonathan Stone <jonathan@DSG.Stanford.EDU>
From: Todd Vierling <email@example.com>
Date: 07/03/2000 21:45:30
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 (firstname.lastname@example.org)