我正在使用epoll_wait编写一个程序来等待64位Linux上的文件描述符，我尝试将一些信息与文件描述符一起放在epoll_event用户数据中。
我知道实际上文件描述符不可能超过32位。只是想知道内核是否保证文件描述符具有特定的范围，或者它只是从小数量计算而不太可能变得非常大？
答案 0 :(得分：9)
添加新文件描述符的epoll_ctl(2)接口采用int fd参数，因此您已经限制在32位范围内（至少在我熟悉的Linux平台上）。
您对所有进程的打开文件数量的/proc/sys/fs/file-max系统范围限制进一步限制; /proc/sys/fs/file-max目前在我的系统上595956。
每个进程都受限于打开文件数量的setrlimit(2) RLIMIT_NOFILE每进程限制。 1024是常见的RLIMIT_NOFILE限制。 （通过/etc/security/limits.conf更改此限制非常容易。）
这是一个罕见的应用程序需要超过1024.完整的32位似乎也不太可能，因为每个打开的文件将需要一些内核内存来表示 - 40亿~280字节struct inode结构（至少）是固定内存的批次。
答案 1 :(得分：3)
您是否计划打开20亿个文件描述符，您是否希望操作系统处理此问题？
在大多数* nix中，返回FD的函数将其作为int返回，其中＆lt; 0是无效的描述符。这些函数返回int中的FD，因此类型的范围是FD的范围。 （减去底片（没有双关语））我会效仿：使用相同的类型，int。
答案 2 :(得分：1)
我在内核中发现了一条注释，表明硬上限是1024 * 1024。
答案 3 :(得分：-1)
64位文件描述符的范围（也适用于32位系统）Linux是0到1023，你不能创建更多的1023打开的文件描述符。你试图打开更多1023文件描述符然后系统将返回错误EBADF（错误的文件描述符），错误没有 - 9.