我正在尝试将 Wine 1.7.13 移植到现代 Cocoa 中。我正在考虑在 XPC 服务的进程中运行 Windows 二进制文件，以实现安全隔离和防崩溃。然而，有一个问题:据我所知，XPC 服务是单例的。一次只允许运行一个XPC服务进程。这是一个问题，因为如果我使用线程使多个 Windows 二进制文件同时运行，一个 Windows 二进制文件中的段错误或其他硬崩溃将导致所有其他二进制文件与它一起崩溃。
如上所述here ，一般认为上述说法是正确的。如果是这样，我似乎无法在单个 XPC 服务进程中实现这种隔离。
我的另一个选择是使用沙箱继承(使 GUI 应用程序 fork 并使用更传统的 IPC 使 Windows 进程相互通信)而不是 XPC 服务。使用它代替 XPC 服务有哪些优点和缺点？据我所知，继承父级沙箱的进程没有自己的权利。还有哪些缺点？
我还了解到 Apple 不鼓励使用沙箱继承而支持 XPC，但这仍然是一个可用的设计决策。他们保留它一定是有原因的。沙盒 Mac App Store 应用程序是否能够以这种方式使用沙盒继承？
最佳答案
我正在做出同样的决定。我一心想要XPC服务，但是当发现有一个XPC服务有多个连接时，我无法使用它们(我的XPC服务将使用第三方提供的插件，所以我想将它们分开，而且 XPC 服务将使用可能无法正确清理的库，因此我希望能够在保持 UI 稳定的同时处理它们 - 好吧，我不必证明这一点 - 我想要每个进程一个进程 -工作就是这样)。
我正在考虑使用 posix_spawn() 的正常子流程模型(我认为这比 fork() WRT 到沙箱的表现更好), CocoaAsyncSocket用于通讯。 我将看看是否可以用 UNIX 套接字替换 CocoaAsynSocket 中 TCP/IP 的使用来加速通信(如果成功的话，我的目的是把它贡献给项目)。 (更新:这已经由 github 用户@jdiehl 完成了。请参阅他的 socketUN branch 以及 issue #88 of the upstream repo 中的讨论)。
对于数据编码，我将使用 Google Protocol Buffers (更新 #2:不；当 NSKeyedArchiver 和 NSKeyedUnarchiver 提供开箱即用所需的一切时，不值得这么麻烦。它们可能无法提供像 Google Protocol Buffers 那样打包的数据，但它们 1) 不需要编写和维护，2) 允许任何类通过实现 NSCoding 协议(protocol)来参与，并且 3) 不需要必须解决跨平台数据交换的问题。
我能看到的唯一可能缺点是我不知道文件书签是否可以传递到子进程并使用(即UI打开一个文件或将一个文件拖到它并希望将文件的访问权限授予工作进程)。我会用我学到的一切来更新这个答案。(最终更新:通过 UNIX 域套接字传递 URL 书签效果很好，而且书签甚至不需要是安全的 -范围书签才能使其发挥作用。对于 XPC 的替代方案没有更多障碍)。
您关于子流程没有自己的权利的断言是不正确的；它们确实如此，并且嵌入到可执行文件中，并且它必须设置“继承沙箱”才能使子进程正常工作。
归根结底，每个应用程序一个 xpc-service 是一个阻碍，所以你别无选择，只能寻找替代方案。
关于macos - XPC 服务的替代方案，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/22084311/