我正在构建一个基于 TCP 的守护进程，用于 HTTP 请求的预处理/后处理。 客户端将连接到Apache HTTPD(或IIS(，自定义Apache/IIS模块会将请求转发到我的TCP守护程序进行进一步处理。 我的守护程序需要向上扩展(但不能横向扩展(以处理大量流量，并且大多数请求都是小而短暂的。 守护程序将在C++中构建，并且必须是跨平台的。
我目前正在研究提升 asio 库，这似乎是天作之合。 但是，我很难理解无堆栈协程与线程池模式的优点。 具体来说，我在这里查看HTTP服务器示例#3和HTTP服务器示例#4：http://www.boost.org/doc/libs/1_49_0/doc/html/boost_asio/examples.html
尽管我在谷歌上搜索了所有内容，但我无法完全理解无堆栈协程服务器的优点，以及它相对于多核系统上的线程池服务器的性能。
根据我的要求，两者中哪一个最合适，为什么？ 请随意"简化"您对无堆栈协程想法的回答，我在这里仍然处于不稳定状态。 谢谢！
编辑：另一个随机的想法/讨论问题：Boost HTTP 服务器示例 #4 被描述为">使用无堆栈协程实现的单线程 HTTP 服务器"。 好的，所以它完全是单线程的(对吧？ 即使在父进程"分叉"给孩子之后？ 请参阅服务器.cpp在示例 #4(...单线程会成为多核系统的瓶颈吗？ 我假设任何阻止操作都会阻止所有其他请求执行。 如果确实如此，为了最大限度地提高吞吐量，我正在考虑一个基于协程的接收数据异步事件，一个用于我的内部阻塞任务的线程池(利用多核(，然后是一个异步发送和关闭连接机制。 同样，可扩展性至关重要。 有什么想法吗？
我最近研究了boost.asio在多核机器上的可扩展性。到目前为止的主要结论是，它确实引入了开销，锁争用和其他上下文切换(至少在Linux上(，请参阅我关于这些主题的一些博客文章：
- http://cmeerw.org/blog/748.html#748
- http://cmeerw.org/blog/751.html#751
我还在asio邮件列表中启动了一个线程，以检查我没有错过任何明显的东西，请参阅 http://comments.gmane.org/gmane.comp.lib.boost.asio.user/5133
如果您主要关心的是性能和可扩展性，那么恐怕没有明确的答案 - 您可能需要进行一些原型设计并查看性能。
如果您有任何阻塞操作，那么您肯定希望使用多个线程 - 另一方面，上下文切换和锁争用会降低多个线程的性能(至少您必须非常小心(。
编辑：只是为了澄清无堆栈协程的东西：它本质上只是一些语法糖，使异步 API 看起来更像顺序/阻塞调用。
您需要测量效果以确定由于难以预测引用位置、CPU 指令缓存、调度延迟等的相对影响而实际发生的情况。
如果您想要启发式猜测，请考虑使用 n 个堆栈大小为 S 的线程，每个线程总是占用 nS 字节，无论每个线程实际使用的堆栈空间是多少。如果这会将您推到页面边界，则可能会显著降低性能。