c++ - IO 饥饿的原因？

Question

我有一种复杂的应用程序，它使用大量的 IO：它包括ffmpeg并进行视频转码（通过软件，没有可用的硬件加速）。这可能不重要，但我想强调它。 所有视频转码功能均独立运行std::thread，libev用于 IO 管理。

硬件细节：

• CPU架构是ARM
• 操作系统是 Debian。

现在，我正在尝试使用它ping来检查特定服务器是否可用。我找到了 ping 的开源，并包含在应用程序中。这是一个完全不同的运行std::thread。

问题：

如果没有正在进行的视频转码，ping 功能将按预期工作。但是，当进行 CPU 密集型转码时，ping 函数 99% 会超时返回。我怀疑存在某种 IO 饥饿，所以我深入研究了 ping 源：

我发现 ping 使用旧select函数调用来检测是否有可用的 I/O。我几乎可以肯定这会导致问题，并且我已经重构了代码： drop select，并付诸libev行动。

但不幸的是，饥饿仍然保持不变。

我几乎接受了这一点，因为视频转码确实给 CPU 带来了巨大的负载（70-80%）。

但是，如果我从 SSH 会话 #A 运行我的应用程序，并从另一个 SSH 会话 #B 运行 ping，我的应用程序可以进行转码，并且会话 #B 上的 ping 不会丢失单个数据包。

结论：

硬件似乎能够与 ping 并行运行我的繁重应用程序。

问题：

我真的很好奇：

• Linux 上每个进程可以使用多少个 IO 有限制吗？（我猜，但我怎么知道这个限制？我怎样才能提高这个限制？我怎样才能检查当前的使用情况？）
• 如果 IO 限制没有任何问题，还有什么会导致这种“饿死”的问题std::threads呢？（无论如何，pings 线程似乎没有阻塞，因为它收到超时。它只是没有收到免费的 IO 操作）更准确：ping 实际上可以发送数据包，但它们似乎没有返回。而且我几乎可以肯定那些 ping 数据包回复会回来，只是我的应用程序没有获得 READ 操作的绿灯。

标签： c++iolibev