macos – XPC服务的替代品

我正在尝试将Wine 1.7.13移植到现代
Cocoa.我正在考虑在XPC服务的进程中运行
Windows二进制文件,以实现安全隔离和防崩溃.但是,有一个问题:据我所知,XPC服务是单身人士.一次只允许运行一个XPC服务进程.这是一个问题,因为如果我使用线程来启用多个Windows二进制文件,一个Windows二进制文件中的段错误或其他硬件崩溃将导致所有其他二进制文件崩溃.

here所述,通常理解上述断言是正确的.如果是这样的话,我似乎无法在单个XPC服务进程中实现这种隔离.

我的另一种选择是使用沙箱继承(使用GUI应用程序分支并使用更传统的IPC使Windows进程相互通信)而不是XPC服务.使用它而不是XPC服务有什么优缺点?我知道继承其父沙箱的进程没有自己的权利.还有哪些其他缺点?

我也理解Apple不鼓励使用沙箱继承来支持XPC,但它仍然是一个可用的设计决策.他们必须保留它是有原因的.沙盒Mac App Store应用程序是否能够以这种方式使用沙箱继承?

最佳答案 我正在做同样的决定.我的心脏设置在XPC服务上,但是一旦发现有一个XPC服务有多个连接,我就不能使用它们(我的XPC服务将使用第三方提供的插件,所以我想让它们分开,并且XPC服务将使用可能无法正常清理的库,因此我希望能够在保持UI稳定的同时处理它们 – 我不应该证明这一点 – 我想要一个进程 – 每个工作就是这样).

我正在考虑使用posix_spawn()的正常子进程模型(我认为这比fork()WRT更好地表现为沙盒),CocoaAsyncSocket用于通信.我将看看是否可以在CocoaAsynSocket中使用UNIX套接字替换TCP / IP的使用以加速通信(如果这样做的话,目的是将其贡献回项目). (更新:这已经由github用户@jdiehl完成了.请参阅他的socketUN branchissue #88 of the upstream repo中的讨论).

对于数据编组,我将使用Google Protocol Buffers(更新#2:Nope;当NSKeyedArchiver和NSKeyedUnarchiver提供开箱即用的所有内容时,不值得麻烦.他们可能无法提供像Google Protocol Buffers一样的数据,但他们1)Don’需要编写和维护,2)通过实施NSCoding协议允许任何类参与,以及3)不必解决跨平台数据交换的问题.

我能看到的唯一可能的缺点是我不知道文件书签是否可以传递给子流程并使用(即UI打开文件或拖动文件并希望将文件的访问权限提供给工作进程).我会用我学到的东西更新这个答案. (最终更新:在UNIX域套接字上传递URL书签工作正常,书签甚至不需要是一个安全范围的书签,这可以工作.对XPC的替代品没有更多的障碍).

您的断言对于没有自己的权利的子流程是不正确的;它们存在并嵌入到可执行文件中,它必须具有“继承沙箱”设置,以使子流程正常工作.

每天结束时,每个应用程序的one-xpc-service是一个显示限制器,所以你别无选择,只能寻找替代方案.

点赞