我正在开发一个在嵌入式 Linux 平台上运行的应用程序(C++ 结合 Qt 用于图形部分)。我需要知道如何将应用程序划分为不同的“核心”，每个核心负责应用程序的不同部分，从而提高应用程序本身的稳定性、效率和安全性。
我的疑问是:将功能划分为线程还是 fork 不同的进程更方便？
让我提供一个应用程序的功能 View :有不同的用户界面，每个界面允许用户做或多或少相同的事情(不要介意数据一致性，我已经解决了这个问题)。这些接口(interface)中的每一个都必须作为独立的(就像同一系统的不同终端)。我希望它们都从同一个“核心”发送和接收消息，该“核心”将负责更新应用程序数据或做其他适当的事情。
实现内部“核心”和用户界面之间划分的最佳方式是什么？
当然我缺少一些知识，但到目前为止我想出了两个替代方案: 1 - 从父亲“核心”中分出一个 child ，让 child 执行一个特定的 UI 程序(我没有这样做的实际经验，所以在这种情况下，我如何才能让父亲和 child 沟通(记住 child 是一个新流程)？) 2 - 为每个核心和 UI 创建不同的线程。
我需要这个划分，因为应用程序需要尽可能稳定，并且能够在崩溃的情况下重新启动 UI。还要记住，整个应用程序不会有无限的可用内存和资源。
在此先感谢您的帮助，问候。
最佳答案
在嵌入式系统中采用单独的进程路线可能是一个不错的选择，原因有几个:
组件解耦:将组件作为单独的进程运行是最终的解耦。当项目变得非常大时通常很有用
安全和权限管理:在嵌入式系统中，某些组件很可能需要更高的权限才能控制设备，而其他组件则是潜在的安全隐患(例如面向网络的组件)，您希望尽可能少地运行尽可能少的特权。其他可能的情况是需要实时线程或能够
mmap()大量系统内存的组件。任何一个的过度分配都会以无法恢复的方式锁定您的系统。可靠:如果系统的某些部分失败而其余部分仍在运行，您可以潜在地重新生成这些部分
构建这样的安排实际上比其他人在这里建议的要容易 - Qt 对 dbus 有很好的支持- 它很好地处理了您的 IPC，并在 Linux 桌面中广泛用于系统管理功能。
对于您所描述的场景，您可能希望守护应用程序的“核心”，然后允许来自 UI 组件的客户端通过 dbus 连接。
关于c++ - 功能实现 : Processes or Threads division?，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/13160464/