过程fork()的过程B.
进程A死亡，因此init采用B.
看门狗创build进程C.
是否有可能C从init B？
更新 ：
或者甚至有可能让C直接采用B（当A死亡时），如果C是在A死之前创build的，而init不成为B的中间父亲？
更新1：
另外，如果能够按照我描述的方式采用一个stream程，这将是一件坏事，或者难以实现，我将不胜感激。
Update-2 – 用例（父母和孩子参考进程）：
我有一个应用程序使用父母来pipe理一大堆的孩子，这依赖于父母的pipe理设施。 为了完成工作，父母依靠通过接收相关的SIGCHLD信号来完成孩子的终止通知。
如果父母自己死于一些意外事件（包括分段事件），我需要重新启动整个“家庭”，因为现在不可能触发孩子终止事件（这也可能是由于段错误）。
在这种情况下，我需要打倒所有的孩子，重新启动整个系统。
避免这种情况的一种可能的方法是build立一个可以接pipe死者父母angular色的备用过程 – 如果它能再次接收到儿童的SIGCHLD信号！
不，绝对不可能。 没有一些讨厌的竞赛条件，它也不能实施。 制作这些API的POSIX人员绝不会创建具有固有竞争条件的东西，所以即使您不感到困扰，您的内核也不会很快得到它。
一个问题是，pid被重用（他们是一个稀缺的资源！），你不能得到一个处理或锁定一个; 这只是一个数字。 所以说，在你的代码的某个地方，你有一个变量，你放置你想要重置的进程的pid。 然后你调用make_this_a_child_of_me(thepid) 。 那么会发生什么？ 与此同时，另外一个进程可能已经退出，并且thepid进程thepid涉及其他一些进程！ 哎呀。 没有unix处理进程的方式的大型重构，就不能提供make_this_a_child_of_me API。
请注意， wait孩子pids的整个处理正是为了防止这个问题：僵尸进程仍然存在于进程表中，以防止其pid被重用。 然后，家长可以通过PID来引用其孩子，相信这个过程不会退出，并且可以重新使用孩子的PID。 如果孩子退出，它的pid被保留，直到父母获得SIGCHLD，或者等待它。 一旦这个过程被收割完毕，它的pid立即抓取，以便其他程序在分叉时立即开始使用，但是父母保证已经知道它。
对更新的响应 ：考虑一个更复杂的方案，在这个方案中，流程被重新分配给他们的下一个祖先。 显然，这不可能在任何情况下都能做到，因为你经常想要一种分手的方式，以确保你避免僵尸。 init非常好地履行了这个角色。 所以，一个过程必须有某种方式来表明它打算采用或不采用其孙辈（或更低）。 这个设计的问题与第一种情况完全一样：你仍然有比赛条件。
如果再次通过pid完成，那么祖父母就会暴露自己的竞争条件：只有父母能够收获一个pid，所以只有父母才真正知道一个pid处理哪个过程。 因为祖父母不能收获，所以不能确定孙子的过程是否从它打算采用的过程（或根据假设的API的工作原理而不同）发生改变。 记住，在负载很重的机器上，没有任何东西可以阻止一个进程从CPU中被分离出来，整个负载可能在那个时候发生变化！ 不理想，但是POSIX必须对此进行解释。
最后，假设这个API不能通过pid工作，但只是普遍地说：“把所有的孙子送给我”或者“把它们发送给init”。 如果在子进程产生后调用它，那么就像以前一样获得竞争条件。 如果之前被调用，那么整个事情就没用了：你应该能够重构你的应用程序来获得相同的行为。 也就是说，如果你在开始产卵的过程中，知道你应该是谁的父母，那你为什么不能一开始就把它们放在正确的位置呢？ 管道和IPC确实能够完成所有需要的工作。
不，你没有办法按照你所描述的方式执行重新装修。