fopen 问题 - 打开文件太多
我有一个在 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
fopen 失败的原因是什么？
编辑：
我编写了简单的单线程测试应用程序。此应用程序可以打开 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);
}
}
}
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:
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 ?
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 ?
#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);
}
}
}
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我想这是你的操作系统的限制。它可能取决于很多因素：文件描述符的表示方式、它们消耗的内存等等。
我想你对此无能为力。也许有一些参数可以调整该限制。
真正的问题是，您真的需要同时打开那么多文件吗？我的意思是，即使您有 100 多个线程尝试读取 100 多个不同的文件，它们也可能无法同时读取它们，并且您可能不会得到比 50 个线程更好的结果。
很难更准确，因为我们不知道您想要实现什么目标。
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.
It's difficult to be more accurate since we don't know what you try to achieve.
我认为在 win32 中，所有 crt 函数最终都会使用下面的 win32 api。所以在这种情况下很可能它必须使用win32的CreateFile/OpenFile。现在，CreatFile/OpenFile api 不仅仅适用于文件（文件、目录、通信端口、管道、邮件槽、驱动器卷等）。因此，在实际应用程序中，根据这些资源的数量，您的最大打开文件可能会有所不同。由于您没有对应用程序进行太多描述。这是我的第一个猜测。如果时间允许，请浏览此 http://blogs。 technet.com/b/markrussinovich/archive/2009/09/29/3283844.aspx
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