“在进程之间传递文件描述符”如何工作？

Question

我阅读了史蒂文斯关于在进程之间传递描述符的示例。 总而言之，他的主程序派生了一个子程序，该子程序执行另一个程序，该程序打开一个文件，通过 unix 域套接字将 integer fd传递回父程序并退出。 Parent 从 socket 接收到这个fd ，并使用fd直接读取文件。

出现了两个问题：

1. 父进程和子进程是两个独立的进程，因此除非它们共享文件描述符表（这不是默认的fork行为，因为CLONE_FILES未设置，AFAIK），否则父进程将无法直接使用子进程的fd 。 Parent 需要在其描述符数组中找到一个 slot，并将 map 放入 child 制作的file object 中。 史蒂文斯提到了这个问题，但代码似乎没有在接收端进行这种映射。
2. 如果子进程不增加引用计数，子进程创建的file object 将在进程退出时被释放。 同样，史蒂文斯在导致代码的描述中提到了这一点，但代码本身似乎并没有这样做。

我找到了一个相关的SO post ，其中父子的角色颠倒了，否则与史蒂文斯的示例相同。 也不确定那个是如何工作的。

我在这里错过了什么吗？ 我的猜测是基于 Linux，也许 unix 足够不同，以至于这两个问题是由 kernel 以某种方式解决的？ 帮助表示赞赏！

Answer 1

扩展整个答案：

1) 当您通过 UNIX 域套接字传递文件描述符时，包含SCM_RIGHTS令牌的消息结构指示kernel在通过套接字时即时复制文件描述符，神奇地出现在另一端FD 值是下一个可用插槽。

正如您在问题中所建议的那样，如果 FD 是按字面传递的（“嘿，另一端，这是 FD#3 要做的事情，祝你好运”）并且 FD 已经在使用中，它就不可能工作。 类似dup的行为是使 FD 在另一端可用的原因。

FD 在两端匹配的唯一一次是巧合。

2) 我不知道 kernel 实际上是如何处理引用计数的，但我相信它被视为dup操作，因此从一端传递到另一端意味着两个进程现在打开了文件，这不是任何一种特殊情况。

当一端关闭文件时，引用计数的处理方式与任何其他类型的dup情况一样。