This is the mail archive of the
libc-hacker@sourceware.cygnus.com
mailing list for the glibc project.
Re: OPEN_MAX/FOPEN_MAX is dynamic?
- To: hjl@lucon.org (H.J. Lu)
- Subject: Re: OPEN_MAX/FOPEN_MAX is dynamic?
- From: Ulrich Drepper <drepper@cygnus.com>
- Date: 19 Oct 1998 16:46:31 -0700
- Cc: linux-kernel@vger.rutgers.edu (linux kernel), libc-hacker@cygnus.com (GNU C Library)
- References: <m0zVGWe-000393C@ocean.lucon.org>
- Reply-To: drepper@cygnus.com (Ulrich Drepper)
hjl@lucon.org (H.J. Lu) writes:
> Ulrich, we need to address it in glibc 2. Also it may have impact
> on __fd_set. It should be large enough to cover most if not all
> cases. I am thinking 8192 or even larger. We can do the conversion
> to the kernel fd size at the run-time.
As Andreas said glibc is almost free of select() calls. Only stupid
RPC code is resisting and probably cannot be fixed without changing
the API.
The "dynamic" adaption of the __fd_set size can be very easily done by
adding #ifndef __FD_SETSIZE around the definition in bits/types.h to
allow the user to define this value. This would be trivial.
Unfortunately it is not possible to define __FD_SETSIZE as something like
#define __FD_SETSIZE (__magically_get_value_from_kernel ())
since it must be a compile time constant.
--
---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com `------------------------