Mention select-freeness.
authordrepper <drepper>
Wed, 25 Nov 1998 14:22:56 +0000 (14:22 +0000)
committerdrepper <drepper>
Wed, 25 Nov 1998 14:22:56 +0000 (14:22 +0000)
FAQ.in

diff --git a/FAQ.in b/FAQ.in
index c15611d..7195efb 100644 (file)
--- a/FAQ.in
+++ b/FAQ.in
@@ -776,6 +776,33 @@ If you need nscd, you have to use a 2.1 kernel.
 
 Note that I have at this point no information about any other platform.
 
+??     I need lots of open files.  What do I have to do?
+
+{AJ} This is at first a kernel issue.  The kernel defines limits with
+OPEN_MAX the number of simultaneous open files and with FD_SETSIZE the
+number of used file descriptors.  You need to change these values in your
+kernel and recompile the kernel so that the kernel allows to use more open
+files.  You don't necessarily need to recompile the GNU C library since the
+only place where OPEN_MAX and FD_SETSIZE is really needed in the library
+itself is the size of fd_set which is used by select.
+
+The GNU C library is now (nearly) select free.  This means it internally has
+no limits imposed by the `fd_set' type.  Instead almost all places where the
+funcationality is needed the `poll' function is used.
+
+If you increase the number of file descriptors in the kernel this for the C
+library that you don't need to recompile the C library it.  The remaining
+select calls are in the RPC code.  If your RPC daemons don't need more than
+FD_SETSIZE file descriptors, you don't need to change anything at all.
+
+{UD} You can always get the maximum number of file descriptors a process is
+allowed to have open at any time using
+
+       number = sysconf (_SC_OPEN_MAX);
+
+This will work even if the kernel changed.
+
+
 ? Source and binary incompatibilities, and what to do about them
 
 ??     I expect GNU libc to be 100% source code compatible with