我正在尝试将Wine 1.7.13移植到现代Cocoa。我正在考虑在XPC服务的进程中运行Windows二进制文件，以实现安全隔离和防崩溃。但是，有一个问题：据我所知，XPC服务是单身人士。一次只允许运行一个XPC服务进程。这是一个问题，因为如果我使用线程来启用多个Windows二进制文件一次运行，一个 Windows二进制文件中的段错误或其他硬崩溃将导致所有其他二进制文件与它崩溃。
正如所提到的here，人们普遍认为上述断言是正确的。如果是这样的话，我似乎无法在单个XPC服务进程中实现这种隔离。
我的另一种选择是使用沙箱继承（使用GUI应用程序分支并使用更传统的IPC使Windows进程相互通信）而不是XPC服务。使用它而不是XPC服务有什么优缺点？我知道继承其父沙箱的进程没有自己的权利。还有什么其他缺点？
我也理解Apple不鼓励使用沙箱继承来支持XPC，但它仍然是一个可用的设计决策。他们必须保留它是有原因的。沙盒Mac App Store应用程序是否能够以这种方式使用沙箱继承？
答案 0 :(得分：2)
我正在做同样的决定。我的心脏设置在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 （ UPDATE＃2 ：不;在NSKeyedArchiver和{{1}时不值得麻烦提供开箱即用的所有内容。他们可能不提供像Google Protocol Buffers一样打包的数据，但他们1）不要求编写和维护，2）通过实现NSKeyedUnarchiver允许任何类参与协议，3）不必解决跨平台数据交换的问题。
我能看到的唯一可能的缺点是我不知道文件书签是否可以传递给子流程并使用（即UI打开文件或拖动文件到它并希望将文件的访问权限提供给工作进程）。我将用我学到的任何内容更新这个答案。（最终更新：在UNIX域套接字上传递URL书签工作正常，书签甚至不需要是安全 - 用于此工作的范围书签。对于XPC的这种替代方案没有其他障碍。
您的断言对于没有自己的权利的子流程是不正确的;它们会嵌入到可执行文件中，并且必须为子流程设置“继承沙盒”才能正常工作。
每天结束时，每个应用程序的one-xpc-service是一个显示停止因素，所以你别无选择，只能找到替代方案。