目前的事实
根据“mod_fcgi不是mod_fastcgi的替代品”和“使用mod_fcgid时出现的问题和多线程FastCGI应用程序”，mod_fcgid并没有被设计为期望FastCGI服务器能够同时处理多个请求，也就是说，并没有被设计为期望FastCGI服务器是多线程的。
前者说：
它们都支持公开的“FastCGI”协议，但是它们控制其FastCGI服务器的方式差别很大。mod_fcgid会快速清除FastCGI服务器并启动新的。
后者说：
看起来mod_fcgid并不知道我的服务器是多线程的，并且能够处理多个请求。
这只是其中的两个引述，还有其他一些引述在其他地方。
连续问题
线程不仅可以节省CPU和内存，避免创建新进程的开销（创建线程比创建进程更轻量级），这可以通过硬件或操作系统性能得到缓解；这也是一个逻辑问题，这个问题不太容易缓解：线程属于同一进程，这不仅是性能问题，而且也是逻辑问题，例如，进程不能共享线程可以共享的内容，因为进程在隔离中运行（除IPC外，但这不是同样的情况）。
至少出于这个逻辑原因，可能会提出多线程FastCGI服务器的问题。当设计为多线程服务器时，FastCGI服务器可能持有上下文（可能很大并且成本高昂，以便在所有请求处理程序之间共享），这是全局的。对于每个并发请求分叉一个新进程将不再允许确保共同的上下文。
问题
上述两个引述是否仍然正确（一个是2011年的，另一个是2010年的）？我在网络上搜索了相关主题，但没有找到任何相关的东西。如果它仍然正确，那么，它将永远是正确的，还是mod_fcgid有一个预期计划，可以意识到多线程FastCGI服务器，并接受这些服务器被设计为处理多个并发请求？