功能实现：进程还是线程划分？

Posted 2023-02-14

【中文标题】功能实现：进程还是线程划分？

【英文标题】：Functionality implementation: Processes or Threads division?

【发布时间】：2012-10-31 14:41:08

【问题描述】：

我正在开发一个在嵌入式 Linux 平台上运行的应用程序（C++ 与 Qt 相结合的图形部分）。我需要知道如何将应用程序划分为不同的“核心”，每个核心负责处理应用程序的不同部分，以提高应用程序本身的稳定性、效率和安全性。

我的疑问是：将功能划分为线程还是分叉不同的进程更方便？

让我提供一个应用程序的功能视图：每个用户界面都有不同的用户界面，允许用户或多或少地做相同的事情（不要介意数据一致性，我已经解决了这个问题）。这些接口中的每一个都必须作为独立的（就像同一系统的不同终端一样）。我希望他们所有人都从同一个“核心”发送和接收消息，该“核心”将负责更新应用程序数据或做其他适当的事情。

实现内部“核心”和用户界面之间划分的最佳方式是什么？

当然，我缺少一些知识，但到目前为止，我想出了两个替代方案： 1 - 从父亲“核心”派生一个孩子，让孩子执行特定的UI程序（我没有这样做的实际经验，所以在这种情况下，我怎样才能让父亲和孩子交流（记住孩子是一个新工艺）？） 2 - 为每个内核和 UI 创建不同的线程。

我需要这个划分，因为要求应用程序尽可能稳定，并且能够在崩溃的情况下重新启动 UI。还要记住，整个应用程序不会有无限的可用内存和资源。

提前感谢您的帮助，问候。

【问题讨论】：

进程通信可以使用文件、数据库或网络连接来完成。恕我直言，所有这三种方法都会降低稳定性、效率和安全性。使用线程。

在 Qt 中，UI 只能在给定进程中的一个线程上运行。

是的，我是 Qt 新手。但我试图仅在 ui 级别使用 Qt，而不是用于内核。

@ahenderson - 可以使用文件、数据库或网络连接来完成进程通信。 在同一台机器上还有许多其他选项可用于进程间通信。管道、命名管道（fifos）、信号量、套接字、套接字对等

【参考方案1】：

在嵌入式系统中采用单独的进程路径可能是一个不错的选择，原因如下：

组件的解耦：将组件作为单独的进程运行是最终的解耦。当项目变得非常大时通常很有用

安全性和权限管理：很可能在嵌入式系统中，某些组件需要提升权限才能控制设备，而其他组件则是潜在的安全隐患（例如面向网络的组件），您希望运行尽可能少的特权。其他可能的场景是需要实时线程或能够mmap() 大量系统内存的组件。任何一种过度分配都会以无法恢复的方式锁定您的系统。

可靠：如果系统的某些部分失败，您可能会重新生成系统的某些部分，而其余部分仍在运行

构建这样的安排实际上比这里的其他人建议的要容易 - Qt 对 dbus 的支持非常好 - 它很好地照顾了您的 IPC，并在 Linux 桌面中广泛用于系统管理功能。

至于您描述的场景，您可能希望守护应用程序的“核心”，然后允许客户端通过 dbus 从 UI 组件进行连接。

【讨论】：

谢谢！我正在慢慢接受这个解决方案......也是由于你提到的重生能力，我也想实施。

【参考方案2】：

在不同的线程中运行 UI 不会给您带来太多额外的稳定性 - 其他线程可能会破坏您的引擎堆，即使您终止线程，它也不会拥有任何资源回收。

您可以通过在引擎和 UI 之间设置一堵非常强大的抽象墙来稍微提高稳定性。所以这也不是完全没用的。

多个进程需要很多圈才能跳过——你需要一种 IPC（进程间通信）方法。

请注意，IPC 和在较小程度上的抽象墙会增加程序的开销。

要问的一个重要问题是“必须在 UI 和引擎之间传递多少数据？” -- 如果数据足够少（例如从 UI 到引擎的“启动任务”，以及从引擎到 UI 的“此任务已完成 50%”），IPC 就不那么麻烦了。如果你是一个实时全屏更新图像的交互式绘画应用程序，IPC 更烦人，更不实用。

现在，一个关于 Qt 和 IPC 的快速 google 告诉我有一个用于嵌入式 linux 的 Qt 扩展，它允许 Qt 信号和插槽在进程之间传递消息：Qt 通信协议 (QCOP)。我在使用此类框架时遇到的一个问题是，与相对简单的协议相比，它很容易导致客户端和服务器状态之间的纠缠，从而损害通信管道另一端的稳定性。

【讨论】：

感谢您的回复！ Ui 和 Engine（实际上是我在开发时自己使用的名称）之间的流量非常少：代表内部协议格式的字符。