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