我正在开发一个在嵌入式Linux平台上运行的应用程序（C ++与Qt结合使用的图形部分）。我需要知道如何将应用程序划分为不同的“核心”，每个核心都负责处理应用程序的不同部分，以提高应用程序本身的稳定性，效率和安全性。
我的疑问是：将功能划分为线程还是分叉不同的进程更方便吗？
让我提供一个应用程序的功能视图：有不同的用户界面，每个用户界面允许用户做或多或少相同的事情（不介意数据一致性，我已经解决了这个问题）。这些接口中的每一个都必须作为独立接口（如同一系统的不同终端）。我希望他们所有人都能从同一个“核心”发送和接收消息，这些消息将负责更新应用程序数据或做其他正确的事情。
实现内部“核心”和用户界面之间划分的最佳方法是什么？
当然，我缺少一些知识，但到目前为止，我想出了两个选择： 1 - 从父亲“核心”分叉一个孩子并让孩子执行一个特定的UI程序（我没有这样做的实际经验所以，在这种情况下，我可以如何让父母和孩子沟通（请记住，孩子是一个新流程）？） 2 - 为每个核心和UI创建不同的线程。
我需要这种划分，因为应用程序需要尽可能稳定，并且能够在崩溃的情况下重新启动UI。还要记住，整个应用程序不会有无限的内存和可用资源。
提前感谢您的帮助，问候。
答案 0 :(得分：2)
在嵌入式系统中，沿着单独的工艺路线走下去可能是一个不错的选择有几个原因：
组件解耦：运行组件作为单独的过程是最终的解耦。当项目变得非常大时通常很有用
安全和权限管理：在嵌入式系统中很可能某些组件需要提升权限才能控制设备，而其他组件则可能存在潜在的安全隐患（例如面向网络的组件）尽可能小的特权。其他可能的场景是需要实时线程或能够mmap()大量系统内存的组件。任何一个的分配都会以一种无法恢复的方式锁定你的系统。
可靠地：如果系统失败，你可能会重新生成部分系统
构建这样的安排实际上比其他人建议的更容易--Qt对dbus有很好的支持 - 它很好地处理了你的IPC，并且在Linux桌面中广泛用于系统管理功能。 / p>
对于您描述的场景，您可能希望对应用程序的“核心”进行守护，然后允许通过UI组件的dbus进行客户端连接。
答案 1 :(得分：0)
在另一个线程中运行UI不会给你太多额外的稳定性 - 另一个线程可以摧毁你的引擎堆，即使你终止线程，它所拥有的任何资源都不会回收
您可以通过在引擎和UI之间拥有非常强大的抽象墙来提高稳定性。所以这不是徒劳的。
多个进程需要大量的环节才能跳过 - 你需要一种IPC（进程间通信）方法。
请注意，IPC以及较小程度的抽象墙可能会增加程序的开销。
要问的一个重要问题是“UI和引擎之间需要传递多少数据？” - 如果数据足够少（如从UI到引擎的“启动任务”，以及“从发动机到用户界面完成此任务50％”），IPC就不那么麻烦了。如果您是一个交互式绘画应用程序，可以对图像进行实时全屏更新，那么IPC会更加烦人且不太实用。
现在，关于Qt和IPC的快速谷歌告诉我，嵌入式Linux有一个Qt扩展，允许Qt信号和插槽在进程之间传递消息：Qt通信协议（QCOP）。我对这样的框架遇到的一个问题是，与相对简单的协议相比，它很容易导致客户端和服务器状态之间的纠缠，从而损害通信管道另一端的稳定性。