C++:在子进程上使用 cin

Question

我正在编写一个早期 fork 的 C++ 程序，我在子进程和父进程中都使用了 std::cout 和 std::cin。出于某种原因，在 Linux 上，cin 似乎没有在子进程中工作；它从不提示输入任何内容。有趣的是，同样的程序在 Mac 上工作得很好。有谁知道为什么会这样？谢谢。

Answer 1

您观察到的是因为 fork 和 exec 模型 ¹。如您所料，所有文件描述符都被复制，但是当两个进程从单个描述符读取时的优先顺序是未定义的 ²。一旦 fork() 返回，它们是父子关系就无关紧要了。

因此，您的情况比仅仅依赖于实现更糟糕。您可能会在同一个系统上得到两个不同的结果。

您的场景称为竞争条件。在这种情况下，两个程序拷贝(父或子)中的哪一个获得哪个字符取决于许多与时间相关的细节。甚至其他进程对您的系统要求的资源也可能影响观察到的行为。

读操作本质上不是原子的²。
如果您可以在任何操作系统上由 parent 和 child 从同一个流中读取相同的字符，则该操作系统没有适本地防止这种竞争情况，这是一个内核问题，应该作为一个可能的错误报告 ^{3 .}

您可以使用信号量或其他同步方法来解决此功能歧义。如果这种机制被正确地使用来保证原子读取，你可能会实现线程安全(或在这种情况下是进程安全)，但你可能仍然没有你想要的。

经典的解决方案可能是决定要读取 std::cin 的两个进程中的哪一个，并在另一个进程中关闭 std::cin。执行此操作的标准机制是测试 fork 调用的返回整数。如果 (fork() == 0) 那么你在 child 中。 (示例在 fork() 文档中给出。)

如果您在两个进程中都需要该值，则可以在 fork 之前使用 pipe() 和 dup2() 并在每个进程中使用正确的 close() 将字符的拷贝从主读取器流式传输到辅助读取器。这就是代理设计模式。如果不同的消息类型应由不同的进程处理，您可能还想实现责任链设计模式。

值得注意的是，由 std::cout 和 std::cerr 包装的输出文件描述符没有竞争条件风险，您可以混合父子 ⁴ 的输出。

.......

[1] POSIX 标准可追溯到早期的 UNIX，最早可追溯到 PDP11。

[2] The Open Group Base Specifications Issue 7 IEEE Std 1003.1-2008, 2016 Edition for pread and read states 手册页，“标准开发人员考虑向管道或 FIFO 添加原子性要求，但认识到由于由于管道和 FIFO 的性质，无法保证读取 {PIPE_BUF} 或有助于应用程序可移植性的任何其他大小的原子性。”

[3] 连续读取相同的消息字节可能违反标准。围绕从输入流中获取字节或字符应该有系统信号量或其他关键代码保护，以便在可以再次读取之前丢弃读取的字节或字符。

[4] 当消息可能超过 POSIX 保证时，从父级和子级写入同一流，即 <= 512 字节的低级别写入将自动进入输出流(根据 Linux“man 7管道”)。此外，为了保持多个作者的时间顺序，需要在每次写入后刷新更高级别的 C 函数或 C++ 方法。但是，如果已知消息在限制范围内并且只执行低级别的 write() 操作，那么拥有多个写入器是完全安全的。