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

Wil*_*ill 5 c linux file-descriptor linux-kernel setrlimit

我正在编写一个需要处理许多开放套接字的服务器,所以我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;
}
Run Code Online (Sandbox Code Playgroud)

现在,我意识到可能没有任何保证,并且我受Linux内核用于实现文件描述符表的任何方法的支配; 但实际上,假设这个程序从Linux内核收到的任何fd的值都小于我在上面设置的MAX_FD_C,这是否合理?

我想每个插槽的数据,以保持尽可能的紧凑它可以简单地使用像数组是指static struct client clients[MAX_FD_C] = {{0}};与使用FD作为索引到客户端结构(这基本上是我自己的版本的FDT的).

Ben*_*igt 3

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