[ CC'd back to current-users, because it should have never been
  removed from the CC line in the first place ... ]

On Tue, Jul 04, 2000 at 12:39:00PM -0700, Jonathan Stone wrote:

 > why? its not any more than IPv6. Are you saying IPv6 is too much
 > of a penalty?

IPv6 support is totally optional, and does not affect every call
to select(2) that a program might make.

 > Jason, thats simply not true. The stnadards do not forbid an
 > FD_SETSIZE greater than 256.  The stnadards _do_ require apps to be
 > able to re-define FD_SETSIZE.  But apps that *can* scale to more than
 > 256 open FDs are not "broken": quite the reverse, actually.  And
 > shipping binary apps that cant scale up is exactly the problem I hit.
 > 
 > You seem to be assuming that 256 is the "sweet spot". I dont know
 > of any hard data which support that.  Do you?

Nor do you have any hard data to show what the "sweet spot" should be
for a general purpose operating system.

Consider an array of desktop workstations.  256 is more than adequate
for systems like that.  Consider small embedded appliances.  Again,
256 is more than adequate.

Simply put, if an application knows it will have a large number of open
descriptors, then the application should use the standards-specified
mechanism for tuning FD_SETSIZE in a way appropriate for that application.

If an application expects to have a large number of file descriptors,
and does *not* use the standards-specified mechanism for tuning select(2),
then it *is* broken.  Applications shouldn't be making assumptions about
the defaults an operating environment provides when there are standardized
knobs available for tuning the environment.

-- 
        -- Jason R. Thorpe <thorpej@zembu.com>