我正在比较 Mac OS X 上可用的不同 IPC 机制（管道、套接字、System V IPC 等），我想看看 Mach 端口与更高级别的替代方案相比如何。但是，我遇到了一个非常基本的问题：跨进程（特别是跨父进程和子进程）获得对端口的发送权限。
与文件描述符不同，端口通常不会转移到派生进程。这意味着必须建立一些其他的传输方式。我能找到的关于这个的唯一相关页面就是这个，他们在更新中声明他们的方法不再有效并且永远不能保证，即使该方法是由苹果工程师在 2009 年提出的。（这意味着替换引导端口，现在这样做会破坏 XPC。）他们建议的替换使用不推荐使用的函数，因此这不是一个非常吸引人的解决方案。
此外，我喜欢旧解决方案的一件事是端口在使用它的进程之间仍然非常私密。不需要广播端口的存在，就像管道（来自pipe调用）一旦分叉就可以工作。（如果有其他解决方案，我可能会接受它，但这有点烦人。）
那么，如何将发送权从父进程传递到 Mach 端口到子进程？
bootstrap_register已弃用但bootstrap_check_in不是，并且可用于注册您的端口，以后可以使用bootstrap_look_up. （不幸的是，这仍然不能提供您正在寻找的隐私）。
推荐的解决方案是根本不直接使用 Mach IPC，而是将您的子进程实现为 XPC 服务，在这种情况下，您可以使用将在后台使用 Mach IPC 的 XPC API，但您不必处理任何细节。您有一个简单的 API 可以在父级中发送 XPC 消息，还有一个简单的 API 可以在客户端中接收 XPC 消息，这也可以轻松地传回回复。该系统将为您处理所有困难的部分。
如果您不能使用 XPC API，请记住，当您注册服务时bootstrap_check_in()（不推荐使用），它不会是私有的，但如果您在用户空间进程中这样做，它将对您的登录名私有session：root 进程看不到，其他用户的进程也看不到。但是，如果您在根进程中执行此操作，则所有会话都可以看到它。
但请注意，您可以控制谁可以向您发送 IPC 消息，谁不可以。mach_msg_audit_trailer_t您可以在接收到 mach 消息时请求 a 。这样您就可以访问audit_token_t发件人的。并使用audit_token_to_pid()您可以获得pid_t发件人的信息。正如您知道孩子的 PID 一样，您可以简单地忽略所有消息（将其传递mach_msg_destroy()以避免泄漏资源），除非消息是由您的子进程发送的。所以你不能避免你的端口是可发现的，但是你可以避免你的子进程以外的任何进程都可以使用这个端口。
最后但并非最不重要的一点是，您可以给您的端口一个随机名称，毕竟只有您的子进程需要知道它，所以您可以在父进程中动态生成一个名称并将其传递给您的子进程，即如果软件扫描端口，则可以看到您的端口，但大多数软件无论如何都只使用硬编码名称。
您可能会尝试的一件事（尽管这是一个严重的黑客攻击）是将异常端口作为继承机制劫持。将自定义端口设置为父级的异常端口，分叉子级，让子级从其异常端口获取自定义端口，将其任务端口发送给父级，父级重置其异常端口，重置子级的异常端口，然后然后两人从那里通过通信渠道继续前进。见task_set_exception_ports()。