虽然在某些情况下多线程更快，但有时我们只想生成多个工作进程来完成工作。这样做的好处是，如果其中一名工作人员崩溃了，主应用程序不会崩溃，并且用户不需要过多担心互锁的东西。
COM+ 的应用程序池似乎是在 Windows 上实现这一目标的好方法。缺点是我们需要为工作进程编写一个 COM+ 包装器。
但是，当我在 Google 上搜索 Application Pooling 时，它的大部分用法似乎都与 IIS 有关。难道其他应用程序（例如科学/图形）没有发现生成多个工作进程很有用吗？
所以有几个问题：
为什么 COM+ 在 IIS 以外的领域没有更流行？如果我编写一个非 IIS 应用程序并想在 Windows 上使用进程管理，我应该使用 COM+ 还是有更好的替代方案？
跨平台的方法是什么？是否有库可以给我一个“进程池”（工作进程将智能地接工作，可以管理等）
You might want to investigate how the apache web server manages process pools. From version 2.0 it runs natively on windows and one of the multi-processing models it supports are process pools. A part of apache is also APR (apache portable runtime), which handles platform-specific issues.
没有人能回答为什么某样东西不受欢迎，因为可能没有人在寻找你正在寻找的东西。.NET 出现后，人们从 COM 转向托管环境，在 .NET 之前，COM 和 ATL 等相关技术实施起来相当痛苦，会崩溃，调试起来也相当困难。
这就是存在托管环境的原因。
但是，从 .NET 4 开始，并行库为用户提供了更多的并行编程能力，您还可以生成和控制其他进程。
对于多平台，您可以寻找 zvrba 的答案。
是的，其他应用程序——尤其是科学应用程序——发现生成多个进程很有用。由于很少有超级计算机运行 Microsoft Windows，因此科学家通常避免使用任何将它们与 Microsoft 平台联系在一起的东西。与 COM 相关的任何内容都无法帮助科学家利用他们用 Fortran 编写的庞大的现有代码库。
选择运行 IIS 的人通常已经喝了 Microsoft Koolaid，因此他们对将自己绑定到 Microsoft 的专有平台的约束更少，这就是为什么特定于 COM 的术语会受到与 IIS 相关的大量点击的原因。
做你想做的事的开放标准之一是消息传递接口。存在几种实现，其中一些在使用 Fortran 的超级计算机上运行。其中一些在使用更性感语言的更便宜的计算机上运行。
没有暴徒冲过 COM 应用程序池的大门，主要是因为两个因素：
COM 应用程序池本质上是为 IIS 创建的。与普通的多线程相比，它有一个非常具体的好处：多个进程彼此完全隔离。在处理稳定性有问题的第三方插件时，这对于数据安全和应用程序稳定性很重要。
科学计算通常不需要在操作之间进行强大的数据安全隔离，我大胆猜测科学计算并不太依赖稳定性有问题的第三方插件。在进行大型数学运算时，您要么使用一个最好是坚如磐石才能认真对待的性感数字库，要么使用您自己的代码，在这种情况下应该修复崩溃并且应该对屡犯者进行打屁股。
哦，除了堆栈溢出之外的所有崩溃都可以在多线程应用程序中捕获和处理，特别是如果它是您自己的代码。
简而言之，COM 应用程序池对于 IIS 以外的任何东西来说都是多余的。
Google 的 webbrowser chrome 是一个多进程架构软件。它是开源的，因此您可以查看其代码并了解如何管理流程。