muduo 后续有在现有代码上增加协程能力的计划吗 · Discussion #579 · chenshuo/muduo · GitHub

我把 muduo-library 邮件列表的回复贴在这里： https://groups.google.com/g/muduo-library/c/OIFG8uF6-Bg/m/I2uO-zcCAgAJ

长话短说：首先，我认为 Go 的并发模型非常好用，写起来比基于事件回调的风格思路要顺畅许多；但是，我目前认为在 C/C++ 里搞用纯户态的 coroutine 没有前途。

coroutine 的本质是对 OS thread 的复用，好处是比 thread 更轻量（10 倍以上），memory locality 也更好，一个程序可以有几百上千的线程 vs. 几万的 coroutine。 坏处是 OS / monitor / debugger 失去对程序的观察力，例如 /proc/pid/task 看不到 coroutine，而且 thread-local storage 和 gettid() 也都废掉了。比如我通过 OS 看到某个 thread 死锁或者 busy-loop，其实很难知道具体是哪个 coroutine 出了问题。一般的 debugger 能看到 OS threads，但看不到你自己实现的 coroutines，特别是当前没有运行的 coroutine。profiler 也不容易正确找出热点，因为看不到正确的 call stack trace。

根据我这几年所学，我认为正确的做法是让内核做上下文切换，但同时可以把调度的任务放到用户态，这样两方面的好处都占住了。

具体说来，如果 Linux 内核接受了 Google 的 switchto() 系统调用，那么 C/C++ 服务端编程就可以采用 Go 一样的编程模型，大家都轻松很多。

ref.

ps. Google 内部用 switchto() 已经很多年了。这也是我对 C++20 里的协程不感兴趣的原因。

陈硕