您好，提前感谢任何人可以提供帮助我理解这一点的帮助
我很好奇关于 IPC 在 Linux 中父子进程之间如何工作的 30.000 英尺视图...我知道有多种类型的 IPC...但我目前正在尝试弄清楚父子进程 IPC 通信是否正常通过 API 到达内核
例如...如果 bash shell 分叉一个 ps 命令进程...我假设 ps 进程使用 IPC 将结果传达回 bash shell...如果这就是它的工作原理，我想弄清楚如果它通过 API 的话...我猜是这样，但我找不到任何具体说明的内容
再次...感谢任何人可以为我提供的任何帮助
答案1
您的示例中实际的 IPC 比您想象的要少得多。
当bash启动ps命令时， ps 进程从其父进程继承各种东西：标准输入、标准输出和标准错误输出的文件句柄； ulimit 设置；环境变量;以及当前的工作目录等等。
该ps命令只是将其输出写入标准输出文件句柄，该文件句柄通常指向用户的 TTY 设备，这是内核 TTY 驱动程序的职责。在控制台会话（无论是 Linux 虚拟控制台还是实际的串行控制台）上，这将直接连接到用户的屏幕；在现代系统上，TTY 设备通常是伪 TTY 从属设备，它会返回到另一个进程：该进程可能是本地 GUI 桌面上的终端仿真程序，或者sshd用于远程登录。bash启动该命令的 shell根本ps不会参与其中。
bash在您的示例中，唯一的进程间通信ps是相当微不足道的：当ps进程结束时，它最初会进入“僵尸”状态：进程内存被释放，它唯一剩下的将是进程表插槽和ps进程退出时产生的返回代码。
内核将向僵尸进程的父bash进程发送一个 SIGCHLD 信号，该进程正在wait(2)寻找它。一旦bash收到信号，它还将收到ps进程结束时产生的返回码。 shell 会将其放入特殊的 shell 变量 中$?，并输出新的命令提示符或继续其正在运行的脚本（如果该ps命令是从脚本启动的）。
同时，由于返回码已成功传递给父进程，内核释放了父进程ps占用的进程表槽位；这样僵尸进程就被搁置了。