Architecture 故障快速还是故障安全？

我正在做一个小项目，涉及创建一个控制台程序，由一个更大的产品在后台运行

该程序一方面与主产品（IP21）通信，另一方面充当服务器，处理多个客户端

我已经开始研究体系结构，并提出了一些基于处理事件（如连接或主产品生成的事件）的方法。客户端处理部分在单独的线程中处理，每个客户端一个线程

但我不同意我的一位同事关于这个架构的看法。他说我应该把反应堆和其他几个运行在主线程中的组件放在一个单独的线程中。主线程应该尽可能简单。我会这样做，这样如果这个部分崩溃，程序就不会崩溃。他说，一个完全不起作用的程序比一次暴力的崩溃要好

我说最好快点失败。如果程序的这一（关键）部分崩溃，就没有理由让它保持活动状态。而且我相信它会给用户带来麻烦；他会注意到有些问题，但如果他查看任务列表（我们的产品是一种任务管理器，它列出了应该运行的任务，并允许轻松跟踪崩溃的任务），他不会注意到程序崩溃

我希望你能通过向一方或另一方提供一些论据来帮助我们；）

---

编辑：感谢您的回答，但我们不同意的是，如果出现严重的编程相关问题（segfault/deadlock/），将reactor和一些其他组件放在一个单独的线程中是否有用。我认为让程序在没有这个线程的情况下运行既危险又毫无意义。

取决于您需要做什么以及它的重要性。如果你能在其他人工作时处理某些失败的步骤，那么就让这些步骤失败并继续下去。（想象一下发送邮件；如果一条消息发送失败，你不希望它阻止其他消息通过。）只有当一个步骤的失败使其他步骤无法可靠完成时，才能使整个过程失败。

使用模式：）

故障保险。但这取决于任务（是否关键）和用户忠诚度。稳定性您失去了一个或全部用户。

使用Proactor模式：）