从子进程中单独并同时捕获 stdout/stderr 会导致总顺序错误 (libc/unix)

Question

我正在编写一个库，它应该在子进程中执行程序，捕获输出，并以逐行(字符串 vector )的方式提供输出。有一个用于 STDOUT 的 vector ，一个用于 STDERR，还有一个用于“STDCOMBINED”，即所有输出均按照程序打印的顺序排列。子进程通过两个管道连接到父进程。一根管道用于 STDOUT，一根管道用于 STDERR。在父进程中我从管道的读取端读取，在子进程中我 dup2() 'ed STDOUT/STDERR 到管道的写入端。

我的问题:我想捕获 STDOUT、STDERR、和“STDCOMBINED”(=均按照它们出现的顺序)。但组合 vector 中的顺序与原始顺序不同。

我的方法:我迭代直到两个管道都显示 EOF 并且子进程退出。在每次迭代中，我从 STDOUT 中读取一行(或 EOF)，从 STDERR 中读取一行(或 EOF)。到目前为止这有效。但是，当我捕获父进程中出现的行时，STDOUT 和 STDERR 的顺序并不相同，就好像我在 shell 中执行程序并查看输出一样。

为什么会这样？我该如何解决这个问题？这有可能吗？我知道在子进程中我可以将 STDOUT 和 STDERR 都重定向到单个管道，但我需要分别使用 STDOUT 和 STDERR 以及“STDCOMBINED”。

---

PS:我熟悉libc/unix系统调用，例如dup2() , pipe()等等。因此我没有发布代码。我的问题是关于一般方法，而不是特定语言的编码问题。我在 Rust 中针对原始 libc 绑定(bind)执行此操作。

PPS:我制作了一个简单的测试程序，其中混合了 5 个 stdout 和 5 个 stderr 消息。这足以重现问题。

Answer 1

At each iteration I read exactly one line (or EOF) from STDOUT and exactly one line (or EOF) from STDERR.

这就是问题所在。仅当这正是子进程中的输出顺序时，才会捕获正确的顺序。

您需要捕捉野兽的异步本质:使管道端点非阻塞，在管道上select*，并在select后立即读取存在的任何数据> 返回。然后您将捕获输出的正确顺序。当然，现在你不能读取“恰好一行”:你必须读取任何可用的数据，这样你就不会阻塞，并维护一个每个管道的缓冲区，在其中附加新数据，提取存在的任何行，将未处理的输出推到开头，然后重复。您还可以使用循环缓冲区来保存一点 memcpy-ing，但这可能不是很重要。

既然你在 Rust 中这样做，我想你已经有了一个可以利用的良好的异步 react 模式(我猜我被 go 宠坏了，并将希望寄托在毫无戒心的人身上)。

*始终更喜欢特定于平台的高性能原语，例如 epoll on Linux , /dev/poll on Solaris , pollset &c. on AIX

另一种可能性是使用LD_PRELOAD启动目标进程，并使用一个专用库来接管glibc的POSIX write，检测对管道的写入，并封装此类写入(并且只有那些)在数据包中，通过在其前面添加一个 header ，该 header 中存储有(自动更新的)进程范围递增计数器以及写入的大小。此类 header 可以在管道的另一端轻松解码，以便以更高的成功机会重新排序写入。