多线程或多处理

Question

我正在为 Linux 设计一个专用的 syslog 处理守护进程，它需要健壮和可扩展，我正在辩论多线程与多进程。

多线程的明显反对意见是复杂性和令人讨厌的错误。
由于 IPC 通信和上下文切换，多进程可能会影响性能。

“Unix 编程艺术”对此进行了讨论 here .

您会推荐基于进程的系统(如 Apache)还是多线程方法？

Answer 1

它们都可以以自己的方式复杂和复杂。

你也可以。从大局来看，您选择哪个可能并不重要。重要的是你做得如何。所以:

做你最有经验的事情。
或者如果你领导一个团队，做团队最有经验的事情。

---线程!---

我做过很多线程编程，我喜欢它的一部分，我不喜欢它的一部分。我学到了很多，现在通常可以编写多线程应用程序而不会太痛苦，但它确实必须以非常具体的方式编写。即:

1) 它必须用非常明确的数据边界来编写，这些边界是 100% 线程安全的。否则，任何可能发生的情况都会发生，而且当你有一个调试器时可能不会发生......加上调试线程代码就像窥视薛定谔的盒子......通过查看那里，其他线程可能有也可能没有有时间处理更多。

2)它必须用测试代码编写，对机器施加压力。许多多线程系统仅在机器压力很大时才会显示它们的错误。

3)必须有一些非常聪明的人拥有数据交换代码。如果有任何方法可以制作快捷方式，那么某些开发人员可能会制作它，并且您将遇到错误的错误。

4) 必须有包罗万象的情况，以最少的麻烦重置应用程序。这是针对由于某些线程问题而中断的生产代码。简而言之:表演必须继续。

- -跨进程! - -

我对基于进程的线程的经验较少，但最近在 Windows 中做了一些跨进程的东西(其中 IPC 是 web 服务调用......哇!)，它相对干净简单，但我遵循一些规则这里也是。总的来说，进程间通信将更加无错误，因为程序可以很好地接收来自外部世界的输入......而且这些传输机制通常是异步的。反正...

1) 定义清晰的流程边界和沟通机制。消息/事件通过，哦，TCP 或 Web 服务或管道或其他任何东西都可以，只要边界清晰，并且在这些边界有很多验证和错误检查代码。

2) 为瓶颈做好准备。代码宽恕非常重要。我的意思是，有时您将无法写入该管道。您必须能够重新排队并重试这些消息，而应用程序不会锁定/抛出异常。

3) 通常会有更多的代码，因为跨进程边界传输数据意味着您必须以某种方式对其进行序列化。这可能是问题的根源，尤其是当您开始维护和更改该代码时。

希望这可以帮助。