windows fopen 问题 - 打开的文件太多
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/3184345/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
fopen problem - too many open files
提问by tommyk
I have a multithreaded application running on Win XP. At a certain stage one of a threads is failing to open an existing file using fopen function. _get_errno function returns EMFILE which means Too many open files. No more file descriptors are available. FOPEN_MAX for my platform is 20. _getmaxstdio returns 512. I checked this with WinDbg and I see that about 100 files are open:
我有一个在 Win XP 上运行的多线程应用程序。在某个阶段，一个线程无法使用 fopen 函数打开现有文件。_get_errno 函数返回 EMFILE，这意味着打开的文件太多。没有更多的文件描述符可用。我的平台的 FOPEN_MAX 是 20。_getmaxstdio 返回 512。我用 WinDbg 检查了这个，我看到大约 100 个文件被打开：
788 Handles
Type Count
Event 201
Section 12
File 101
Port 3
Directory 3
Mutant 32
WindowStation 2
Semaphore 351
Key 12
Thread 63
Desktop 1
IoCompletion 6
KeyedEvent 1
What is the reason that fopen fails ?
fopen 失败的原因是什么？
EDIT:
编辑：
I wrote simple single threaded test application. This app can open 510 files. I don't understand why this app can open more files then multithreaded app. Can it be because of file handle leaks ?
我编写了简单的单线程测试应用程序。此应用程序可以打开 510 个文件。我不明白为什么这个应用程序可以打开比多线程应用程序更多的文件。可能是因为文件句柄泄漏吗？
#include <cstdio>
#include <cassert>
#include <cerrno>
void main()
{
int counter(0);
while (true)
{
char buffer[256] = {0};
sprintf(buffer, "C:\temp\abc\abc%d.txt", counter++);
FILE* hFile = fopen(buffer, "wb+");
if (0 == hFile)
{
// check error code
int err(0);
errno_t ret = _get_errno(&err);
assert(0 == ret);
int maxAllowed = _getmaxstdio();
assert(hFile);
}
}
}
采纳答案by ferosekhanj
I think in win32 all the crt function will finally endup using the win32 api underneath. So in this case most probably it must be using CreateFile/OpenFile of win32. Now CreatFile/OpenFile api is not meant only for files (Files,Directories,Communication Ports,pipes,mail slots,Drive volumes etc.,). So in a real application depending on the number these resources your max open file may vary. Since you have not described much about the application. This is my first guess. If time permits go through this http://blogs.technet.com/b/markrussinovich/archive/2009/09/29/3283844.aspx
我认为在 win32 中，所有 crt 函数最终都会使用下面的 win32 api。所以在这种情况下，它很可能必须使用 win32 的 CreateFile/OpenFile。现在 CreatFile/OpenFile api 不仅仅用于文件（文件、目录、通信端口、管道、邮件插槽、驱动器卷等）。因此，在实际应用程序中，根据这些资源的数量，您的最大打开文件可能会有所不同。由于您没有对应用程序进行太多描述。这是我的第一个猜测。如果时间允许，请通过此http://blogs.technet.com/b/markrussinovich/archive/2009/09/29/3283844.aspx
回答by ereOn
I guess this is a limitation of your operating system. It can depend on many things: the way the file descriptors are represented, the memory they consume, and so on.
我想这是您的操作系统的限制。它可能取决于许多因素：文件描述符的表示方式、它们消耗的内存，等等。
And I suppose there isn't much you can do about it. Perhaps there is some parameter to tweak that limit.
我想你对此无能为力。也许有一些参数可以调整该限制。
The real question is, do you really need to open that much files simultaneously ? I mean, even if you have 100+ threads trying to read 100+ different files, they probably wont be able to read them at the same time, and you'll probably not get any better result than having, as an example, 50 threads.
真正的问题是，您真的需要同时打开那么多文件吗？我的意思是，即使您有 100 多个线程试图读取 100 多个不同的文件，它们也可能无法同时读取它们，并且您可能不会得到比例如 50 个线程更好的结果.
It's difficult to be more accurate since we don't know what you try to achieve.
很难做到更准确，因为我们不知道您想达到什么目的。
