'passing file descriptors between processes' 是如何工作的？
How does 'passing file descriptors between processes' work?
我阅读了史蒂文斯关于在进程之间传递描述符的示例。总而言之，他的主程序派生了一个 child，它执行另一个程序，打开一个文件，通过 unix 域套接字将整数 fd 传回 parent 并退出。 Parent 从套接字接收这个 fd，并使用 fd.
直接读取文件
出现两个问题：
- Parent 和 child 是两个独立的进程，因此除非它们共享文件描述符 table（这不是默认的
fork 行为，因为 CLONE_FILES 未设置，据我所知），parent 将无法直接使用 child 中的 fd。 Parent 需要在其描述符数组中找到一个槽并将其映射到 child 制作的 file object。史蒂文斯提到了这个问题，但是代码似乎没有在接收端做这个映射。
- 如果child 不增加引用计数，child 生成的
file object 将在进程退出时释放。再一次，史蒂文斯在导致代码的描述中提到了这一点，但代码本身似乎并没有这样做。
我找到了一个相关的，其中parent和child的作用是颠倒的，否则和史蒂文斯的例子一样。也不知道它是如何工作的。
我是不是漏掉了什么？我的猜测是基于 Linux，也许 unix 足够不同以至于内核以某种方式解决了这两个问题？感谢帮助！
扩展整个答案：
1) 当您通过 UNIX 域套接字传递文件描述符时，包含 SCM_RIGHTS 标记的消息结构指示 内核 复制文件描述符在通过套接字时运行，神奇地出现在另一端，FD 值是下一个可用插槽。
正如您在问题中所建议的那样，如果按字面意义传递 FD ("hey other end, here is FD#3 to do stuff with, good luck with that") 并且该 FD 已经在使用中，它就不可能工作。 dup-like 行为使 FD 在另一端可用。
唯一一次 FD 在两端匹配是巧合。
2) 我不知道内核实际上是如何处理引用计数的，但我确信它被视为一个 dup 操作，因此从一端传递到另一端意味着两个进程现在有文件打开，这不是任何一种特殊情况。
当一端关闭文件时，引用计数的处理方式与任何其他 dup 情况一样。
我阅读了史蒂文斯关于在进程之间传递描述符的示例。总而言之，他的主程序派生了一个 child，它执行另一个程序，打开一个文件，通过 unix 域套接字将整数 fd 传回 parent 并退出。 Parent 从套接字接收这个 fd，并使用 fd.
出现两个问题：
- Parent 和 child 是两个独立的进程，因此除非它们共享文件描述符 table（这不是默认的
fork行为，因为CLONE_FILES未设置，据我所知），parent 将无法直接使用 child 中的fd。 Parent 需要在其描述符数组中找到一个槽并将其映射到 child 制作的fileobject。史蒂文斯提到了这个问题，但是代码似乎没有在接收端做这个映射。 - 如果child 不增加引用计数，child 生成的
fileobject 将在进程退出时释放。再一次，史蒂文斯在导致代码的描述中提到了这一点，但代码本身似乎并没有这样做。
我找到了一个相关的
我是不是漏掉了什么？我的猜测是基于 Linux，也许 unix 足够不同以至于内核以某种方式解决了这两个问题？感谢帮助！
扩展整个答案：
1) 当您通过 UNIX 域套接字传递文件描述符时，包含 SCM_RIGHTS 标记的消息结构指示 内核 复制文件描述符在通过套接字时运行，神奇地出现在另一端，FD 值是下一个可用插槽。
正如您在问题中所建议的那样，如果按字面意义传递 FD ("hey other end, here is FD#3 to do stuff with, good luck with that") 并且该 FD 已经在使用中，它就不可能工作。 dup-like 行为使 FD 在另一端可用。
唯一一次 FD 在两端匹配是巧合。
2) 我不知道内核实际上是如何处理引用计数的，但我确信它被视为一个 dup 操作，因此从一端传递到另一端意味着两个进程现在有文件打开，这不是任何一种特殊情况。
当一端关闭文件时，引用计数的处理方式与任何其他 dup 情况一样。