是否可以采用流程？

Question

进程 A fork()s 进程 B。

进程 A 死亡，因此 init 采用 B。

看门狗创建进程 C。

C 有没有可能从init 采用 B？

---

更新：

或者如果 C 是在 A 死之前创建的，而 init 没有成为 B 的中间父级，甚至可以让 C 直接采用 B（当 A 死时）？

---

更新 1：

另外，如果有任何 cmets 解释为什么有可能采用我所描述的方式将是一件坏事或难以实施，我将不胜感激。

---

Update-2 - 用例（父子进程指代进程）：

我有一个应用程序使用父母来管理一大群孩子，这些孩子依赖于父母的管理设施。为了完成其工作，父母依赖于收到孩子终止的通知，这是通过接收相关的SIGCHLD 信号来完成的。

如果父母本身因某种事故（包括段错误）而死亡，我需要重新启动整个“家庭”，因为现在不可能在孩子终止时触发某些事情（这也可能是由于段错误）。

在这种情况下，我需要关闭所有孩子并重新启动整个系统。

避免这种情况的一种可能方法是建立一个备用进程，它可以接管死去的父母的角色...... - 如果它可以再次接收到继子的SIGCHLD 信号！

Answer 1

我不知道有什么好的方法可以做到这一点，但拥有它的一个原因是运行的进程可以独立运行或向父进程添加功能。收养将作为事件的结果发生，由（尚未）孩子知道，但父母不知道。即将出生的孩子会向父母发送信号。父母会收养（或不收养）孩子。一旦成为父进程的一部分，父/子进程将能够对事件做出反应，而在单独站立时，它们都无法对事件做出反应。

这种对接行为可以编码到应用程序中，但我不知道如何实时执行。还有其他方法可以实现相同的功能。可以接受对接孩子的父母可以以父母以前不知道的新颖方式扩展其功能。

Answer 2

不，绝对不可能。如果没有一些讨厌的竞争条件，它也无法实现。制作这些 API 的 POSIX 人员永远不会创建具有固有竞争条件的东西，因此即使您不介意，您的内核也不会很快得到它。

一个问题是 pid 会被重复使用（它们是稀缺资源！），而且您也无法获得句柄或锁定；这只是一个数字。因此，比如说，在您的代码中的某处，您有一个变量，您可以在其中放置要重新设置的进程的 pid。然后你打电话给make_this_a_child_of_me(thepid)。那时会发生什么？与此同时，其他进程可能已经退出，thepid 更改为引用其他进程！哎呀。如果不对 unix 处理进程的方式进行大规模重组，就无法提供make_this_a_child_of_me API。

请注意，对子 pid 进行waiting 的整个处理正是为了防止这个问题：进程表中仍然存在僵尸进程，以防止其 pid 被重用。然后，父进程可以通过它的 pid 引用它的子进程，确信进程不会退出并让子进程 pid 重用。如果子进程退出，它的 pid 将被保留，直到父进程捕获 SIGCHLD 或等待它。一旦进程被收割，它的 pid 立即可供其他程序在它们 fork 时开始使用，但父进程保证已经知道它。

对更新的响应：考虑一个更复杂的方案，其中进程被重新设置为它们的下一个祖先。显然，这不可能在所有情况下都这样做，因为您经常想要一种与孩子断绝关系的方式，以确保您避免僵尸。 init 很好地完成了这个角色。因此，流程必须通过某种方式来指定它打算收养或不收养其孙辈（或更低）。这种设计的问题与第一种情况完全相同：您仍然获得竞争条件。

如果再次由 pid 完成，则祖父母将自己暴露于竞争条件：只有父母能够获得 pid，因此只有父母真正知道 pid 与哪个进程一起使用。因为祖父母不能收割，所以不能确定孙进程没有改变它打算采用的进程（或不承认，取决于假设的 API 的工作方式）。请记住，在负载很重的机器上，没有什么可以阻止进程在几分钟内从 CPU 中取出，而整个负载可能在这段时间内发生了变化！不理想，但 POSIX 必须考虑到这一点。

最后，假设这个 API 不能通过 pid 工作，而只是一般地说，“将所有孙子发送给我”或“将它们发送给 init”。如果在子进程生成后调用它，那么您会像以前一样获得竞争条件。如果它之前被调用过，那么整个事情就没用了：您应该能够稍微重构您的应用程序以获得相同的行为。也就是说，如果您在开始生成子进程之前就知道谁应该是谁的父进程，那么为什么不能一开始就以正确的方式创建它们呢？管道和 IPC 确实能够完成所有需要的工作。

Answer 3

不，您无法按照您描述的方式强制执行 Reparenting。