muduo 后续有在现有代码上增加协程能力的计划吗

[uuuuu-diwu]

看着似乎没有办法 发邮件到 [email protected]

We're writing to let you know that the group you tried to contact (muduo-library) may not exist, or you may not have permission to post messages to the group. A few more details on why you weren't able to post:

• You might have spelled or formatted the group name incorrectly.
• The owner of the group may have removed this group.
• You may need to join the group before receiving permission to post.
• This group may not be open to posting.

就在这里提问题吧
muduo 后续有在现有代码上增加协程能力的计划吗
基于当前的 reactor 代码，在这上面增加简单的调度能力和上下文保存与 restore 能力应该就能实现协程
大致思路如下：

1. 整体分为三种协程，
   1.1 主协程-不分配执行栈，
   1.2 event_loop 协程-执行event dispatch 并调用回调，需要单独分配执行栈
   1.3 其他协程-执行用户设定的 function，需要单独分配执行栈
2. 每次执行 io 操作时，将当前函数的上下文保存到一个 io 队列中，并设置一个超时回调和 io 事件 ready 回调，回调的逻辑是将协程移动到可运行队列。
3. 每次执行 io 操作时，去可运行队列中寻找下一个协程上下文，并切换到这个上下文，如果没有找到下一个可运行的协程，则直接切换到执行 event_loop 的协程，如果有 io 事件 ready，则会回调对应的回调函数
4. 为常用的 io 系统调用编写协程版本的函数

[chenshuo]

我把 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.

• https://news.ycombinator.com/item?id=24084348
• https://news.ycombinator.com/item?id=24688225
• https://lkml.org/lkml/2020/7/22/1202
• https://www.youtube.com/watch?v=KXuZi9aeGTw
• https://technodocbox.com/Unix/67839755-User-level-threads-with-threads-paul-turner.html

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

陈硕

[uuuuu-diwu]

感谢作者的答复和 ref，又有新的东西可以学习了

[adlternative]

您好，陈硕，经过几天对 您说的这个 Google swithto() 资料的阅读，我大致可以明白它基于 futex_swap() 实现，尽管现在这个补丁似乎被 LKML 抛弃了。

这个 futex_swap() 似乎是在让当前线程 1 执行 futex_wait(futex1) 进入睡眠, 并让对期望切换的线程 2 执行唤醒操作 futex_wake(futex2) , 然后同理线程 2 也可以通过同样的方式唤醒线程 1 并让自己进入睡眠.

但我仍然有一些疑问：

1. 在 [1] 中："Take stack size for example: assuming the kernel stack is 10kB, if your thread itself uses 10kB of stack, you've cut the theoretical memory advantage of M:N down from the cited 1000x to a mere 2x"，为何这个 switch_to() 会让理论的内存优势会下降如此严重呢？
2. 似乎最近该补丁作者的新补丁是在 UMCG API 是做文章，意图让 Google 另一套个用户空间调度框架 Fibers 开源 ，这是否意味着 switch_to() 将只会在 Google 内部闭源使用？

[1] https://news.ycombinator.com/item?id=24084348
[2] https://lore.kernel.org/lkml/[email protected]/

[Celthi]

问一句，协程（如co_await, co_yield）方式的支持，只是让用户写代码更方便一点，还是用的muduo的架构，所以陈硕说的问题和对协程的支持不冲突吧？
相当于用C++20的协程支持能力，包装一下muduo，然后用户可以使用co_await， co_yield来使用muduo框架。

[adlternative]

问一句，协程（如co_await, co_yield）方式的支持，只是让用户写代码更方便一点，还是用的muduo的架构，所以陈硕说的问题和对协程的支持不冲突吧？
相当于用C++20的协程支持能力，包装一下muduo，然后用户可以使用co_await， co_yield来使用muduo框架。

是的我觉得 co_await 和 co_yield 可以使用，但目前 c++20 的协程原语写起来并不方便，同时程序的性能很可能没有提升。

[chenshuo]

我不认为协程可以简单地与高性能划等号。

根据 SIGCOMM ’21 上的文章 Understanding Host Network Stack Overheads 的测试结果，在服务器硬件上，现在 Linux 内核网络协议栈（内核 5.4+）可以用 1 个 TCP 连接（单core）打满 40Gbps 网卡的单向带宽，但需要多个 cores 和多个连接才能用完 100Gbps 网卡带宽。也就说单线程 1 个 TCP 连接就可以发送或接收 5GBytes/s。

在程序的网络吞吐量接近这个量级之前，谈性能优化恐怕为时过早。

作为对比，i7-8665U CPU 算 SHA1 的速度大约是 1.2GBytes/s/线程，只有 TCP 单连接吞吐量的 1/4 左右。就是说，如果设计不当，checksum 这一步可能会成为数据传输的瓶颈。

[etorth]

我用过的协程体会是：能优化代码结构，让逻辑更清晰，并不一定带来普适的性能提升。
用了协程后如果切换后执行它的线程变了tls就废了，这个非常恶心。

[hilbertdu]

我不是做服务器linux开发的，但我本人完全赞同陈硕说的switchto语义完全可以替代coroutine的说法，coroutine本质上还是基于回调的语法糖，是没有办法做到使用“同步”代码块来表示“异步”行为的，从使用者的角度来说并不比直接基于回调的方式要减轻多少心智负担。可以说即没有解决干净语法层面的问题，对性能也起不了多大帮助。而真正从底层解决问题的思路就是把os context switch提升到user context switch，直接让玩家自己做cooperative scheduling，这个玩意儿其实就是fiber。
2015年顽皮狗的客户端引擎完全基于fiber做的job system，每帧跑3000 - 5000个job毫无压力。也许是给游戏引擎多线程模型拉开了一扇新的大门。
本人也基于windows的Fiber实现了一套job system，同时支持手动代码构建task graph，理论上调度的效率可以做到最优。
https://github.com/hilbertdu/FiberLib

[morganwu277]

使用“同步”代码块来表示“异步”行为， 这是 结构化并发 的概念，而非 coroutine 的目的，搞混了， 只是很多已经实现了协程的方案里面也会实现 使用“同步”代码块来表示“异步”行为 方案而已，但是本质上是两个概念。

结构化并发也可以作用于线程。

[microcai]

reactor 就没法实现协程。

协程解决的是什么问题？协程解决的是回调地狱的问题。
reactor都没有回调地狱问题，何来协程呢？

至于所谓的协程性能高。其实并不是协程性能高。而是 proactor 模型带来的性能高。协程是用来解决 proactor 模型容易有回调地狱这个缺陷的。
既然 muduo 是 reactor 模型，那么就没有回调地狱。没有回调地狱，就没有使用协程的必要。

你要求 muduo 支持协程，实际上是在要求 muduo 变成一个 proactor 模型。
这自然是不可接受的。

[LunarStore]

你不看discuss和issue的吗？，muduo不屑用协程

…

---原始邮件--- 发件人: ***@***.***> 发送时间: 2024年12月5日(周四) 下午2:06 收件人: ***@***.***>; 抄送: ***@***.***>; 主题: Re: [chenshuo/muduo] muduo 后续有在现有代码上增加协程能力的计划吗 (Discussion #579) reactor 就没法实现协程。 协程解决的是什么问题？协程解决的是回调地狱的问题。 reactor都没有回调地狱问题，何来协程呢？ 至于所谓的协程性能高。其实并不是协程性能高。而是 proactor 模型带来的性能高。协程是用来解决 proactor 模型容易有回调地狱这个缺陷的。 既然 muduo 是 reactor 模型，那么就没有回调地狱。没有回调地狱，就没有使用协程的必要。 你要求 muduo 支持协程，实际上是在要求 muduo 变成一个 proactor 模型。 这自然是不可接受的。 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>