OPEN_MAX在哪里为Linux系统定义?

时间:2012-12-26 15:46:46

标签: linux gcc system-calls

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

根据Beginning Linux Programming 4 th Edition,Page 101:

  

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

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

3 个答案:

答案 0 :(得分:5)

值得一提的是,Beginning Linux Programming的第4版于2007年出版;它的一部分可能有点过时了。 (这不是对这本书的批评,我没有读过。)

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

另一个宏FOPEN_MAX应该是相似的;我想不出OPEN_MAXFOPEN_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.
*/

答案 1 :(得分:4)

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

以下是一些文档: 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也占用了3个插槽]。如果rlimit设置为5,那么您只能打开自己的2个文件。

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

答案 2 :(得分:2)

我建议使用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.
...
...

希望它可以帮到你