Date: Sun, 15 Oct 1995 08:26:21 +1000 From: Bruce Evans <bde@zeta.org.au> To: volf@oasis.IAEhv.nl Cc: current@freebsd.org Subject: Re: kern/781: MAX_OPEN and FD_SETSIZE Message-ID: <199510142226.IAA27494@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>>Description: > The OPEN_MAX define in the kernel configuration can be used to have > a large number of open file descriptors (e.g. 512), OPEN_MAX shouldn't be defined in the kernel configuration. Defining it there doesn't affect the value defined in <sys/syslimits.h>, which may be relied on by applications. E.g., to fix the current problem (*), FD_SETSIZE could reasonably be min(256, OPEN_MAX). This number would then be compiled into binaries and would be invalid if OPEN_MAX was defined as more than 256 in the kernel config. (*) This doesn't actually fix the problem because OPEN_MAX isn't actually a constant. OPEN_MAX is only used in the kernel as the default (soft) limit on the number of fd's. setrlimit(RLIMIT_NOFILE, rlp), where *rlp specifies a large limit, has the same effect as defining OPEN_MAX to a large value only in the kernel. No good fix is evident. There is no such thing as a struct with variable length, so the fd_set type can't be resized at runtime. >... > The select() fails at runtime if it is called with a nfds > FD_SETSIZE, > because it is compiled with the FD_SETSIZE value, and does not > know about OPEN_MAX > 256 >>Fix: > > Preferable automatic generation of the types.h file from kernel > configuration by /usr/sbin/config. This doeesn't work because of the binary compatibility issues. >Please, let me know the status of this bug report (maybe I did something >wrong). All OK. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510142226.IAA27494>