7

OPEN_MAX是定义单个程序允许的最大打开文件数的常量。

根据开始 Linux 编程第 4版，第 101 页：

限制，通常由limits.h 中的常量OPEN_MAX 定义，因系统而异，...

在我的系统limits.h中，目录 中的文件/usr/lib/gcc/x86_64-linux-gnu/4.6/include-fixed没有这个常量。我看错了limits.h还是自 2008 年以来位置发生了OPEN_MAX变化？

4

3 回答 3

6

值得一提的是，《Beginning Linux Programming 》第 4 版于 2007 年出版；它的一部分可能有点过时了。（这不是对这本书的批评，我还没有读过。）

OPEN_MAX至少在 Linux 系统上，这似乎已被弃用。原因似乎是可以同时打开的文件的最大数量不固定，因此扩展为整数文字的宏不是获取该信息的好方法。

FOPEN_MAX还有另一个应该类似的宏；我想不出一个原因，如果OPEN_MAX和FOPEN_MAX，如果它们都被定义，应该有不同的值。但是FOPEN_MAX是 C 语言标准规定的，所以系统没有不定义它的选项。C标准说FOPEN_MAX

扩展为一个整数常量表达式，该表达式是实现保证可以同时打开的最小文件数

（如果“最小”这个词令人困惑，它保证一个程序可以一次打开至少那么多文件。）

如果要当前最大可以打开的文件数，看一下sysconf()函数；在我的系统上，sysconf(_SC_OPEN_MAX)返回 1024。（sysconf()手册页指的是一个符号OPEN_MAX。这不是计数，而是由 . 识别的值sysconf()。而且它没有在我的系统上定义。）

我在我的 Ubuntu 系统上搜索了OPEN_MAX（单词匹配，所以不包括FOPEN_MAX），发现了以下内容（这些显然只是简短的摘录）：

/usr/include/X11/Xos.h：

# ifdef __GNU__
#  define PATH_MAX 4096
#  define MAXPATHLEN 4096
#  define OPEN_MAX 256 /* We define a reasonable limit.  */
# endif

/usr/include/i386-linux-gnu/bits/local_lim.h：

/* The kernel header pollutes the namespace with the NR_OPEN symbol
   and defines LINK_MAX although filesystems have different maxima.  A
   similar thing is true for OPEN_MAX: the limit can be changed at
   runtime and therefore the macro must not be defined.  Remove this
   after including the header if necessary.  */  
#ifndef NR_OPEN
# define __undef_NR_OPEN
#endif
#ifndef LINK_MAX
# define __undef_LINK_MAX
#endif
#ifndef OPEN_MAX
# define __undef_OPEN_MAX
#endif
#ifndef ARG_MAX
# define __undef_ARG_MAX
#endif

/usr/include/i386-linux-gnu/bits/xopen_lim.h：

/* We do not provide fixed values for 

   ARG_MAX      Maximum length of argument to the `exec' function
                including environment data.

   ATEXIT_MAX   Maximum number of functions that may be registered
                with `atexit'.

   CHILD_MAX    Maximum number of simultaneous processes per real
                user ID. 

   OPEN_MAX     Maximum number of files that one process can have open
                at anyone time.

   PAGESIZE
   PAGE_SIZE    Size of bytes of a page.

   PASS_MAX     Maximum number of significant bytes in a password.

   We only provide a fixed limit for

   IOV_MAX      Maximum number of `iovec' structures that one process has
                available for use with `readv' or writev'.

   if this is indeed fixed by the underlying system.
*/
于 2012-12-27T16:18:12.550 回答
5

除了 cste 给出的链接，我想指出，有一个/proc/sys/fs/file-max条目提供了系统在任何给定时间可以打开的文件数量。

这是一些文档： https ://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/8.2/html/Performance_Tuning_Guide/system-tuning.html

请注意，这并不是说可以保证您可以打开那么多文件 - 如果系统耗尽了某些资源（例如“没有更多可用内存”），那么它很可能会失败。

FOPEN_MAX 表示 C 库允许打开这么多文件（至少，如所讨论的那样），但可能首先发生其他限制。例如，SYSTEM 限制为 4000 个文件，而一些已经运行的应用程序打开了 3990 个文件。那么您将无法打开超过 7 个文件 [因为 stdin、stdout 和 stderr 也占用了三个插槽]。如果rlimit设置为 5，那么您只能打开 2 个自己的文件。

在我看来，知道是否可以打开文件的最好方法是打开它。如果失败了，你必须做其他事情。如果您有一些需要打开许多文件的进程[例如，在具有 256 个内核和每个内核 8 个线程的机器上进行多线程搜索/比较，并且每个线程使用三个文件（文件“A”、“B”和“diff”）] ，那么您可能需要确保您的 FOPEN_MAX 允许在开始创建线程之前打开 3 * 8 * 256 个文件，因为无法打开其文件的线程将毫无意义。但是对于大多数普通应用程序，只需尝试打开文件，如果失败，告诉用户（日志或其他内容），和/或重试...

于 2012-12-26T16:49:04.533 回答
3

我建议使用魔法grep来找到这个常数/usr/include：

grep -rn --col OPEN_MAX /usr/include

...
...
/usr/include/stdio.h:159:   FOPEN_MAX   Minimum number of files that can be open at once.
...
...

希望对你有帮助

于 2012-12-26T16:19:39.533 回答