问题发现

做了一个进程中pipe通信的Demo，结果发现在第二个子进程结束后，又将第一次的结果输出出来了，本来预期结果是第二次进程仅有第二次的进程才对，竟然包含第一次的结果？

代码如下：

结果竟然在111之后，也就是父进程执行之后又再次出现p1的相关信息？

问题解决

我先去查找pipe的相关资料，pipe中的信息在读取一次之后就不能再读取了，看来不是pipe的作用，为此我直接删掉了pipe的相关代码。

如下所示：

结果竟然是两个111，为什么父进程第二次创建子进程会再次执行它上一行代码里面所包含的111？到这里更加觉得奇怪。

询问后有同事认为是孤儿进程的问题。

如果是 systemd，它的策略是接管孤儿进程，并将其变为独立进程路士磊 202118640111 2023/11/15 19:27:45
这个过程会重新分配pcb
重新分配pcb <- pid 被充值
然后到底是输出多少111就取决于运气了（
孤儿进程独立后，pid 不为0 ，会执行15行的代码
和 A 的表现几乎一致了
如果第二种可能持续发生，可能会有一堆 111

由于我对孤儿进程了解较少，查询资料后仍然有困惑，为什么我尝试输出很多次都是111，甚至换了设备同样是111呢？

再次返回到对fork的搜索上。

发现了这样的解释：

竟然是缓冲区的问题，之前没考虑到这一点，于是饶了弯路，但在我本地的环境\n并不会触发缓冲区的输出，还是要手动的fflush()才可以。

至此问题解决。