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

我正在编写一个需要处理许多开放套接字的服务器,因此我使用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,这是否合理？

我想保持每个套接字数据尽可能紧凑,这可能意味着只使用像静态struct客户端客户端这样的数组[MAX_FD_C] = {{0}};并使用fd作为客户端结构的索引(基本上是我自己的FDT版本).

解决方法

POSIX标准中有一些函数已经假设了这一点.看看FD_SETSIZE,select(),FD_SET.