这个问题可能有点学术性;但令人费解的是。
假设在Windows（8+）机器上有一个进程（在本例中是一个服务），比如proc_0。我可以发送一个请求来运行特定的东西。这是由proc_0开始（比如说）proc_a完成的。 proc_a然后产生proc_b，而proc_b又可能产生proc_c，这又可能产生proc_d
我们将在此流程树中结束：
proc_0
| _proc_a
| ____ proc_b
| ______ PROC_C
| ________ proc_d
让我们说我只影响proc_b中发生的事情。
好的，我们想要的是如果proc_a死了，proc_a的每个孩子都应该死掉。
如果proc_0杀死proc_a，则会出现问题。在窗户上这个＆＃34;孤儿＆＃34; proc_b和它（及其子女）保持活力。
现在，proc_b，我可以决定做什么的唯一过程，实际上是在观察会发生什么，即如果proc_a死了它会杀死它的孩子。精细。 proc_b可能知道proc_c的子proc_d，因此它会杀死它，然后杀死proc_c。
但是这里理论上......在proc_c实际上被proc_b杀死之前，proc_c只是产生了另一个子proc_z。 proc_b现在已经不知道proc_z ...当proc_c最终死亡时会变成孤儿（请记住，我不能对proc_c的行为做任何事情，或者因为某些其他原因而被杀死了）。现在流程如下：
proc_0
proc_b（孤儿，但我知道）
proc_z（孤儿，但我不知道）
proc_b我可以终止我的自我，但是有没有办法检测到proc_z实际上是由我知道的并且刚刚被杀死的进程启动的（即它也应该死掉）。
好的，我可以找到孤立的proc_z，但是，我怎么能决定它是否可以杀死？ proc_z将没有父进程，但可能有一个旧的父进程pid。即使我可以知道这个pid实际上是我从proc_c中知道的那个pid，但我没有机会实际检测proc_z是否实际上是由proc_c启动的还是一个完全不同的进程也死了，操作系统恰好重用了我的pid死了proc_c
与现实相关，这是关于我在windows jenkins奴隶身上所看到的;这导致我插入proc_b，因为取消作业会使子进程运行。 jenkins可能会对此进行更新，但是＆＃34;理论＆＃34;我认为，问题 - 决定是否杀死这个孤儿 - 仍在使用中。