到目前为止的事实
根据“<a href="http://www.apachelounge.com/viewtopic.php?t=4385">mod_fcgi 不是 mod_fastcgi 的替代品”和“<a href="http://mail-archives. apache.org/mod_mbox/httpd-users/201008.mbox/%3C4C7C286B.6020703@codexterous.com%3E">mod_fcgid 和多线程 FastCGI 应用程序的问题”，mod_fcgid并非旨在期望 FastCGI 服务器能够处理一次多个请求，即没有设计为期望 FastCGI 服务器是多线程的。
前者说：
它们都支持已发布的“FastCGI”协议，但它们控制 FastCGI 服务器的方式有很大不同。mod_fcgid 快速消除 FastCGI 服务器并启动新的服务器。
后者说：
似乎 mod_fcgid 不知道我的服务器是多线程的并且能够处理多个请求。
这只是其中的两个引用，其他地方还有一些。
连续的问题
线程不仅是为了节省 CPU 和内存，避免创建新进程的开销（众所周知，创建线程比创建进程更轻），而且可以通过硬件或操作系统性能来缓解；这也是一个逻辑问题，不太容易缓解：线程属于同一个进程，这不仅是性能，也是逻辑，例如。进程无法共享线程可以共享的内容，因为进程是独立运行的（以 IPC 为模，但不一样）。
至少出于这个逻辑原因，多线程 FastCGI 服务器的问题可能会被提出。FastCGI 服务器可能包含一个上下文（在进程之间共享可能很大且成本很高），当它被设计为多线程服务器时，它对所有请求处理程序都是全局的。为每个并发请求派生一个新进程不再允许确保公共上下文。
问题
上述两个报价是否仍然正确（一个是 2011 年，另一个是 2010 年）？我在网上搜索了该主题，但找不到任何相关内容。如果它仍然是正确的，那么它是否总是正确的，或者是否有预期的计划mod_fcgid来了解多线程 FastCGI 服务器并接受这些可能旨在处理多个并发请求的服务器？