From owner-freebsd-hackers  Wed Oct 18 01:32:37 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id BAA05316
          for hackers-outgoing; Wed, 18 Oct 1995 01:32:37 -0700
Received: from netcom22.netcom.com (bakul@netcom22.netcom.com [192.100.81.136])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA05311
          ; Wed, 18 Oct 1995 01:32:36 -0700
Received: from localhost by netcom22.netcom.com (8.6.12/Netcom)
	id BAA18615; Wed, 18 Oct 1995 01:30:42 -0700
Message-Id: <199510180830.BAA18615@netcom22.netcom.com>
To: Bruce Evans <bde@zeta.org.au>, terry@lambert.org
Cc: current@freefall.freebsd.org, hackers@freefall.freebsd.org
Subject: Re: getdtablesize() broken? 
In-reply-to: Your message of "Wed, 18 Oct 95 17:04:23 +1000."
             <199510180704.RAA16305@godzilla.zeta.org.au> 
Date: Wed, 18 Oct 95 01:30:40 -0700
From: Bakul Shah <bakul@netcom.com>
Sender: owner-hackers@FreeBSD.org
Precedence: bulk

Bruce:
> The select() interface has pointers to fd_set's, so it doesn't rule out
> using arrays of fd_set's.  I think only the FD_ macros and the
> documentation would need to be rewritten.

fd_set is a struct containing just an array of longs.  You
don't need to make an array of fd_set -- just use a bigger
array (big enough to hold the highest valid fd).

Me in an earlier message:
>> This is well and good for *user* programs.  Most programs don't
>> want to bother with changing FD_SETSIZE and kernel changes
>> I am proposing are transparent to such programs.

What I meant is this:
If the _kernel_ treats select()'s readfds, writefds,
exceptfds as ptrs to int-arrays (and *not* fd_set ptrs), and
allocates kernel copies of the same dynamically, this change
removes the fixed limit and is transparent to user programs.
All old programs using select continue working (for whatever
value of FD_SETSIZE provided descriptors limit is high
enough).  You can even do this and it will work:

	cc -DFD_SETSIZE=33 foo.c
	cc -DFD_SETSIZE=333 foo.c

You can also use dynamically or statically allocated long-
int-arrays instead of fd_set and things will keep working
(though lint will complain).

Terry responded:
>How do I make a program which doesn't guard using FD_SETSIZE the max fd
>it tries to select upon suddenly have a larger statically or stack
>declared bitvector array?

Your program should either use fd_set (and implicitly
FD_SETSIZE) or just do dynamic allocation of long-int-arrays
to hold the bitvectors.  (BTW, gcc will allow you to do
dynamic alloc. on the stack).

Basically if your program uses fixed size sets, fd_set is
fine -- just redefine FD_SETSIZE to what you want.  If your
program wants to adjust the array size dynamically you are
better off using long-int-arrays.  But in the latter case
you can't use the FD_ macros.

What I do in C++ is define a class with methods like add,
remove, ismember, members (to return a list of ints
corresponding to set bits) etc.  You can do something
similar in C (but to avoid the overhead you'd've to use
macros or inline functions).

Bruce again:
> Anyway, the kernel needs to handle an arbitrary FD_SETSIZE for
> compatibility.  There is no reason why the Linux FD_SETSIZE should be as
> limited as the FD_SETSIZE that the kernel happened to be compiled with.

That is exactly the point I have been trying to make.  Thanks!
I should've just made the change - would've been quicker!!

--bakul