期望在 Linux 中 fd < 打开文件描述符的最大数量是否合理？答案

【问题标题】：Is it reasonable to expect that in Linux, fd < maximum number of open file descriptors?期望在 Linux 中 fd < 打开文件描述符的最大数量是否合理？
【发布时间】：2013-05-18 05:03:36
【问题描述】：

我正在编写一个需要处理许多打开的套接字的服务器，所以我使用setrlimit() 来设置打开文件描述符的最大数量（作为 root，在删除权限之前），如下所示：

#include <sys/resource.h>
#define MAX_FD_C 9001

if (setrlimit(
      RLIMIT_NOFILE, &(struct rlimit){.rlim_cur = MAX_FD_C, .rlim_max = MAX_FD_C}
    ) == -1) {
    perror("Failed to set the maximum number of open file descriptors");
    return EXIT_FAILURE;
}

现在，我意识到可能不会有任何保证，而且我受制于 Linux 内核用于实现文件描述符表的任何方法；但在实践中，假设这个程序从 Linux 内核接收到的任何 fd 的值都小于我上面设置的 MAX_FD_C 是否合理？

我想让每个套接字数据尽可能紧凑，这可能意味着简单地使用像 static struct client clients[MAX_FD_C] = {{0}}; 这样的数组并使用 fd 作为客户端结构的索引（这基本上是我自己的 FDT 版本） .

【问题讨论】：

是的，文件描述符将在 0
编程时不要假设任何事情。它让你活得更久。说真的。
@RandyHoward：我认为假设是保持我们理智和高效的必要条件。
您可以假设当代码不工作时会被要求修复的代码是由最初做出许多无根据假设的人编写的。 ;-)
嗯...至少我来到 SO 并在这里发布了我的问题，以便首先审查我的假设。此外，我尽可能避免假设，但在这种情况下，不假设将需要更大的数组，从而导致更多的缓存未命中，并且性能明显变差。这一切都是因为我只有 99.9% 的把握，而不是 100%。Don't assume anything while programming. It makes you live longer. 有计划地承担风险是什么让一个人成功并生活得更快乐？

标签： c linux linux-kernel file-descriptor setrlimit

【解决方案1】：

POSIX 标准中的一些函数已经假设了这一点。看看FD_SETSIZE、select()、FD_SET。

【讨论】：

我猜这是来自select 手册页：An fd_set is a fixed size buffer. Executing FD_CLR() or FD_SET() with a value of fd that is negative or is equal to or larger than FD_SETSIZE will result in undefined behavior. Moreover, POSIX requires fd to be a valid file descriptor.?
@Will：请注意，这并不能保证您永远无法获得高于FD_SETSIZE 的文件描述符，但open 确实保证生成的文件描述符是“一个小整数”并且其他东西在不小的时候就会破裂。如果您愿意，您还可以使用dup2 将超出范围的 fds 移动到范围内（显然，选择一个未使用的条目）。
感谢您的回复，我注意到open 的手册页中的以下句子：The open() function shall return a file descriptor for the named file that is the lowest file descriptor not currently open for that process。我读到这在逻辑上意味着任何新的 fd 要么小于任何打开的 fd，或者正好比最大的打开 fd 大一个，这反过来证明没有 fd 可以大于设置的最大值（因为达到fd > max，你必须打开比 max 更多的 fd）。也许您可以将此添加到您的答案中（或者我想我可以自己创建一个答案）。
再说一次，虽然这适用于open()，但它可能不一定适用于其他功能，如accept()。哦，好吧，我想我已经足够相信了。
@Will：来自socket 和accept 的返回值也会传递给select，因此它们需要遵循相同的规则。