通过pid

Question

考虑两个过程A和B，标准输入和输出流通过管道相互连接以形成闭环。假设，作为exec的结果，这两个过程并不直接意识到它们之间的关系。

如果B突然终止（例如通过发送SIGKILL），A怎么知道B死了？或者至少让A死了

快速查看情况，其中Cmd是A和B客户端：

Answer 1

＆＃34; A＆＃34;在写入消费者被杀的管道时收到SIGPIPE信号。

您可以为SIGPIPE注册处理程序并正常处理它。

Answer 2

据我了解，您唯一需要处理的是管道。没有任何其他可能会帮助您执行exec，特别是如果我们假设正在运行的程序 A 不是专门为此交互设计的。因此，让我们考虑一下您可以用管道做什么。

当 B 终止时，无论出于何种原因，其所有打开的文件句柄都将关闭。这包括管端的手柄。

如果 A 此后尝试写入其自己的stdout，并且读取结束未在任何过程中打开， ^* 则A将收到{ {1}}，正如@indianant观察到的那样。该信号的默认处置是终止该过程，因此 A 将会死亡，除非它已经改变了该信号的处置。除非 A 中运行的程序是您提供的程序，否则 A 是否会更改SIGPIPE的处置是您无法控制的。

但 B 终止时， A 可能会被禁止从标准输入读取。假设 B 是保持该管道写入结束的唯一进程， A 将在其标准输入上看到EOF。这不会自动导致 A 终止，但它可以适当地响应该事件，这可能导致它自然终止。此外， A 可能会在终止前收到 B 写入的数据;如果 A 通过尝试写入其标准输出进行响应，则适用上一段。

但是，除非 A 实际在其标准流上执行I / O，否则这些都不适用。如果您正在寻找某种异步通知，那么您可能需要将其作为第三个进程的责任。为此目的最简单的方法是为 A 和 B 提供一个共同的父流程，可能是专门用于此目的的流程。父母将通过SIGPIPE通知，或者在其中一名儿童死亡时从SIGCHLD或wait()返回;然后它可以采取适当的行动，例如杀死另一个孩子。请注意，这不适用于 A 作为 B 或waitpid()的父级，因为信号处理程序不会通过exec传输，除了可能{{1 } vise versa。

^* 特别要确保在 A 中打开读取结束，方法是在exec之前关闭它。