Date: Wed, 18 Oct 95 01:30:40 -0700 From: Bakul Shah <bakul@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? Message-ID: <199510180830.BAA18615@netcom22.netcom.com> In-Reply-To: Your message of "Wed, 18 Oct 95 17:04:23 %2B1000." <199510180704.RAA16305@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510180830.BAA18615>