Date: Wed, 18 Oct 1995 17:04:23 +1000 From: Bruce Evans <bde@zeta.org.au> To: bakul@netcom.com, terry@lambert.org Cc: bde@zeta.org.au, current@freefall.freebsd.org, hackers@freefall.freebsd.org Subject: Re: getdtablesize() broken? Message-ID: <199510180704.RAA16305@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> > I don't see where this massive amount of runtime work is really worth it. >> >> It is not massive amount of runtime work. Changes are >> fairly straight forward. The runtime cost is small. >> ... >Basically, all of the user space code that uses the standard-since-4.2 >sys/types.h definitions would need to be rewritten. This is what I >meant. 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. >> 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. >??? >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? Don't use the standard FD_ macros. 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. Fixed limits defeat binary compatibility. This is particularly annoying for fixed limits like OPEN_MAX that aren't actually fixed even on the host OS. See <sys/syslimits.h> for a long list of bogus limits. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510180704.RAA16305>