爲Linux系統定義的OPEN_MAX在哪裏？

OPEN_MAX是定義單個程序允許的最大打開文件數的常量。爲Linux系統定義的OPEN_MAX在哪裏？

根據年初的Linux編程4 ^日版，第101頁：

的限制，通常是由limits.h中恆OPEN_MAX定義，因系統不同而不同，...

在我的系統中，目錄/usr/lib/gcc/x86_64-linux-gnu/4.6/include-fixed中的文件limits.h沒有這個常量。我是否看錯了limits.h或者自從2008年以來更改了OPEN_MAX的位置？

來源

2012-12-26 asheeshr

http://stackoverflow.com/questions/8225186/portable-equivalent-of-open-max –

參見'FOPEN_MAX'，在''定義 - 儘管@ cste的評論中提到的問題可能有更多有用的信息。進程可以打開的文件數量限制不一定是固定的。 –

@KeithThompson我現在要求更多的是學習而不是應用。那麼，沒有恆定的「OPEN_MAX」？ – asheeshr

爲什麼它的價值，Beginning Linux Programming的第4版是2007年出版;它的一部分可能有點過時。（這不是對本書的批評，我沒有讀過。）

看起來OPEN_MAX已被棄用，至少在Linux系統上。原因似乎是，可以同時打開的最大文件數量不是固定的，因此擴展爲整數字面值的宏不是獲取該信息的好方法。

還有另外一個宏應該是相似的FOPEN_MAX;我想不出爲什麼OPEN_MAX和FOPEN_MAX，如果它們都定義了，應該有不同的值。但是由於C語言標準規定了FOPEN_MAX，所以系統沒有選擇不定義它。 C標準說FOPEN_MAX

擴展爲一個整數常量表達式是執行的保證可以是打開的文件的最小數目的同時

（如果詞「最小值」是混亂的，它是一個程序可以同時打開至少的很多文件，提供了保障。）

如果你想文件可以的當前最大數量打開，看看sysconf()的功能;我的系統上，sysconf(_SC_OPEN_MAX)收益1024（該sysconf()手冊頁是指一個符號OPEN_MAX，這是不是一個數，而是由sysconf()識別的值。而且這不是我的系統上定義。）

我搜索過OPEN_MAX我的Ubuntu系統上（詞匹配，所以不包括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-27 16:18:12

我建議使用的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-26 16:19:39 JoseLSegura

'FOPEN_MAX' - 最小值？不應該是最大的？ – asheeshr

除非它涉及最大'FOPEN_MAX'的最小可能值？ – asheeshr

@AshRj：'FOPEN_MAX'保證你可以打開*至少*那麼多文件。 –

除了通過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-26 16:49:04

當你強調SYSTEM時，系統和程序的運行實例有不同的限制嗎？ – asheeshr

@AshRj：是的，還有每個進程的限制，請參閱「ulimit -n」shell命令，或者對於{get，set} rlimit（）使用RLIMIT_NOFILE。 – janneb

修改爲涵蓋其他限制。 –

爲Linux系統定義的OPEN_MAX在哪裏？

回答

相關問題