gpt4 book ai didi

c - 处理大量 FILE 指针

转载 作者:行者123 更新时间:2023-11-30 19:10:04 25 4
gpt4 key购买 nike

TLDR

有没有一种干净的方法可以通过整个程序处理 1 到 65535 个文件,而不分配全局变量,其中很多可能永远不会使用,并且不使用链接列表(Windows 上的 mingw-w64)

长篇故事

我有一个 tcp 服务器,它从许多客户端(最多 65535 个)分配数据并将它们保存在数据库中。 “数据库”是一个目录/文件结构,如下所示: data\%ADDR%\%ADDR%-%DATATYPE%-%UTCTIME%.wwss 其中 %ADDR% 是地址,%DATATYPE% 是数据类型%UTCTIME% 是第一个数据包到达此套接字时的 UTC 时间(以秒为单位)。因此,每次接受新连接时,都应按指定创建此文件。

如何正确处理 65535 FILE 句柄?第一个想法:全局变量。

FILE * PV_WWSS_FileHandles[0x10000]
//...
void tcpaccepted(uint16_t u16addr, uint16_t u16dataType, int64_t s64utc) {
char cPath[MAX_PATH];
snprintf(cPath, MAX_PATH, "c:\\%05u\\%05u-%04x-%I64d.wwss", u16addr, u16addr, u16dataType, s64utc);
PV_WWSS_FileHandles[u16addr] = fopen(cPath, "wb+");
}

这看起来非常懒惰,因为所有地址同时连接的情况可能永远不会发生,因此它会分配从未使用过的内存。

第二个想法:创建一个存储句柄的链表。这里的坏处是,它可能会非常消耗 CPU 资源,因为我想在多线程环境中执行此操作,并且当 f.e. 400个线程同时接收新数据,它们都必须遍历整个链表才能找到FILE句柄。

最佳答案

你真的应该看看其他人的代码。我想到了 Apache 。假设您可以在计算机上打开 2^16 个文件句柄。这是一个调整的问题。

现在...首先考虑什么是文件句柄。它通常是 C 标准库的构造...它保存打开文件的数组(文件句柄是该数组的索引)。如果您想保留这些句柄上的其他信息,您可能也想保留一个数组。

如果您担心占用的资源,请考虑每个打开的网络文件句柄都会导致操作系统保留 4k 或 8k(可配置)缓冲区 x2(输入和输出)以及文件句柄结构。这很容易在操作系统级别使用千兆字节的内存。

当您执行相当于 select() 的操作时,如果您的操作系统很智能,您将获得文件句柄 — 这样您就可以使用它来索引该文件句柄的“要做什么”的数组。如果你的 select() 不聪明,你将不得不检查每个打开的文件句柄......这将使任何性能尝试变得可笑。

我说“看看其他人的解决方案”。我是认真的。最初的 apache 每个进程使用一个文件句柄(有效)。当 select() 很愚蠢时,这是一个很好的策略。糟糕的是,通常情况下,愚蠢的操作系统会唤醒太多进程 --- 但那是 1999 年左右。现在 apache 默认使用它的混合 MPM 模型......这是多线程和多任务的混合体。它为每个进程(线程)一定数量的客户端提供服务,并且具有多个进程。这使得每个进程的文件数量更加合理。

如果您再往前追溯,为了简单起见,可以使用 inetd 方法。每次连接 fork 一个(比如)ftp 进程。世界上最大的 ftp 服务器(ftp.freebsd.org)就这样运行了很多年。

不要将文件句柄存储在文件中(愚蠢)。不要将文件句柄存储在链接列表中(您最流行的代码路线会杀死您)。利用文件句柄是小整数这一事实并使用数组。 realloc() 可以在这里提供帮助。

呵呵...我看到其他 FreeBSD 人也参与了...在评论中。无论如何...如果您打算尝试在一个进程中保持这么多事情打开,请查找 FreeBSD 和 kqueue()。

关于c - 处理大量 FILE 指针,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/41903715/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com