为 UI 的一部分创建另一个流程是个好主意吗？

Posted 2023-02-16

【中文标题】为 UI 的一部分创建另一个流程是个好主意吗？

【英文标题】：Is creating another process for a part of the UI a good idea?

【发布时间】：2020-11-23 21:45:05

【问题描述】：

抱歉，我无法在此处发布专有代码。基本上，它是一个 Mac GUI 应用程序。代码没有正确设计以利用 异步 概念。一切都在主线程上处理，不可能一夜之间改变设计。因此，我不想使用 dispatch_async(…) 解决方案。

问题的上下文是：我有一个在主线程上运行的耗时任务。在处理任务时，我尝试根据任务的完成百分比（从 0% 到 100%）更新/重绘进度条（NSProgressIndicator）。但是，因为任务运行在主线程上，所以主线程被阻塞了，事件队列中的任何更新/重绘事件都要等到主线程有机会看到，所以进度条没有更新/在任务执行期间完全重绘。

我正在考虑的解决方案是创建另一个处理进度条绘图的应用程序（带有 .exe 文件）。在主应用程序中，我将创建另一个进程并让该进程执行另一个应用程序。可以使用Boost inter-process message queue 将任务的完成百分比从主应用发送到其他应用。

我希望了解此解决方案的优点和缺点，因此任何想法都将不胜感激！

【参考方案1】：

您也可以从同一进程中的线程执行此操作。进程间消息队列仍然有效，尽管任何线程安全的解决方案都足够了。

一般来说，在进程外运行一些重要的任务是值得的。内核级进程隔离具有线程永远无法拥有的好处：

内存空间分离（安全） 权限分离（其他进程可能在不同的安全上下文中运行）

因此，在处理不受信任的输入或不可靠的第三方库代码时，您可以获得主进程的稳定性保证。

但是，就您的目的而言，这听起来有点矫枉过正。

【讨论】：

非常感谢您的想法，@sehe！我能问一下为什么你认为这是一个矫枉过正的事情吗？有哪些缺点超过了该方法的好处？

启动进程的成本很高（甚至可能受到权限限制），同步和共享数据要困难得多。简而言之，这里没有任何安全/可靠性优势。

也许你可以为一个非常简单的后台任务编写最少的代码，无论是多处理还是多线程版本，看看工作量的区别是什么。

我一定会在某个时候这样做。我只是想向有经验的人学习，这样我就不会犯太常见的错误。再次感谢@sehe！