背景：我有一个大型的现有进程（它恰好在 AIX 上，所以基本上是 POSIX 语义），它是一个更大系统的一部分。现有流程设计为连续运行。此过程的一个新要求是处理一种新型的复杂输入流。为了降低风险，我决定分叉/执行一个子进程来执行实际的输入处理，这将现有的主进程与崩溃或因格式错误的输入数据而挂起等问题隔离开来。
子进程从stdin读取数据，处理后写入stdout。我已经设置了所有通信管道，因此我可以将输入数据从主进程传递给子进程，并以其他方式读取输出，这一切都工作正常（非阻塞以避免死锁等）。只要主进程从外部源接收（有限）输入流，子进程就存在。
我的问题是关于管柄本身的。主进程通过调用通知子进程输入流已完成close()在连接到孩子的标准输入的管道上。只要only该管道写入端的句柄由主进程持有。如果主进程由于其他一些不相关的原因决定分叉怎么办？这将创建two管道写入端的句柄，这意味着当我尝试关闭标准输入管道的写入端时，孩子不会注意到，因为还有另一个打开的写入端句柄。另一个打开的手柄是我无法控制的。
我知道有FD_CLOEXEC我可以在文件描述符上设置位，以便在文件描述符发生错误时自动关闭exec()已经完成了。但是，这并不能防止主进程分叉但不执行的情况。
这个问题的一般解决方案是什么？我只能想到几个想法：
- 确保（通过检查）现有进程不会在不执行 exec 的情况下任意分叉。这也许是可能的，但不是通用的解决方案。
- 在启动时，分叉一个长期存在的帮助程序进程，其唯一职责是定期分叉/执行执行实际处理的子进程。这样助手的句柄上下文是已知的并且可以很好地控制。然而，这很烦人，因为助手需要某种方式来知道输入流已经结束，而不是关闭its stdin.
Very few No standard system libraries fork without exec. It's quite unusual. There is no close-on-fork facility in Unix or Linux, and I doubt it on AIX. There are loadable kernel extensions on AIX if you really care that much. Presumably you know about fcntl for close on exec. If your co-workers are writing exec-less forks, then I can't offer much assistance.
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
