Hello, if you raise FD_SETSIZE in /usr/include/bits/typesizes.h and then compile a software which uses select(), this software will be able to handle more than 1024 FDs. Recompiling glibc, the kernel or whatever else is not necessary.
I tested this solution with UnrealIRCd and 8000 clients. Unfortunately, I don't know enough about the way glibc works, but I found this in the FAQ of the debian libc6 source package: -------- 2.25. 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 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 select free. This means it internally has no limits imposed by the `fd_set' type. Instead all places where the functionality is needed the `poll' function is used. If you increase the number of file descriptors in the kernel you don't need to recompile the C library. -------- Would it be possible to add a #ifndef FD_SETSIZE around the definition in /usr/include/bits/typesizes.h in order to give other software the possibility to change the value without modifying the system headers? Regards, Christoph -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org