我正在使用epoll_wait编写一个程序来等待64位Linux上的文件描述符，并尝试将一些信息与文件描述符放在epoll_event用户数据中。
我知道在实践中文件描述符不太可能超过32位。 只是想知道的是，内核保证文件描述符有一个特定的范围，或者它只是从小而不是很大，而不是很大？
添加新文件描述符的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结构（至少）是固定的记忆。
你打算打开20亿个文件描述符，你希望操作系统来处理这个吗？
在大多数* nixs中，返回FD的函数将其作为int返回，其中<0是无效的描述符。 这些函数以int返回FD，所以类型的范围是FD的范围。 （减去否定（没有双关语意））我会效仿：使用相同的类型，因此， int 。
我在内核中发现了一个注释，表示硬盘上限是1024 * 1024。
64位文件描述符的范围（也适用于32位系统）Linux是0到1023，不能创建多于1023个已打开的文件描述符。 您尝试打开更多然后1023文件描述符然后系统将返回错误EBADF（错误的文件描述符），错误号-9。