异步 VS 协程

loken

各位晚上好，我的疑问是有两个的。

肖志宏在B站之前有一个分享《RTC级联和QUIC协议》，在这个视频的第 24 分钟左右比较了异步与协程 解析复杂协议 的代码可读性。如下图所示：

我觉得他例子说得很对，确实协程可以做到很好的可读性，例如 SRS RTMP 里面的 expect_message() 函数
他只需要一次 expect_message() 调用就完成了 多个 chunk 的合并 跟 connect 请求的解析。如下：

协程的优势在我这篇文章《DNS查询lookupdns程序分析-上》里也有介绍。

但是异步编程的可读性真的很低吗？我还是想实际看一下 ZLMediaKit 解析 RTMP 的代码。

因为在 FFmpeg 发送端，一个完整的 RTMP Message 会拆成多个 chunk 进行发送。那在接收端，ZLMediaKit 是怎么合并多个 chunk 成一个完整的 RTMP Message 的？

可以截图一下关键代码我看一下吗？

小助手

看下 RtmpProtocol::handle_rtmp 这个函数，这是 ZLMediaKit 处理 RTMP 的地方。

小助手

其实异步都是状态机。

loken

小助手嗯嗯，这就是我的第二个疑问。

异步编程必须的状态机管理性能消耗是不是大于协程切换的上下文开销？还是说是一样的？

信

loken 异步与协程的性能是一个数量级的，没什么多大区别。
两种方式都可以极大提高线程时间片使用率，减少线程切换，跟多线程阻塞模型相比，这才是高效的主要原因

loken

信那我肯定选协程，既然是一个数量级的性能，协程的代码看起来可读性更好。

信

loken 协程可读性确实好，但只能单线程，看使用场景吧。

loken

信可以通过二次开发 StateThread，改造成 多线程场景也能使用。

信

loken 是的，可以

信

协程跟异步模型比，相当于上下文环境当做了状态机，把异步模型业务代码做的事情技术化了，其实本质上没区别

我十年前写过一篇wiki，讲了多进程-多线程-异步-协程这四种模型的演进，不过这几种模型各有用途，并不一定是替换的关系

我的 wiki 找不到了，不过网上也有一些是别人写的，你搜关键词就行。

loken

信嗯嗯，我也觉得是这样，上下文其实就是状态机的另一种表达。官网好像提到了这一点。

The State Threads library combines the advantages of all of the above architectures. The interface preserves the programming simplicity of thread abstraction, allowing each simultaneous connection to be treated as a separate thread of execution within a single process. The underlying implementation is close to the EDSM architecture as the state of each particular concurrent session is saved in a separate memory segment.

我翻译一下上面这段话，他说 会话的状态保存在每个协程单独的内存段里面，我觉得这其实就是状态机的另一种表达，或者说是另一种实现。

FAQ 里面还有下面这段描述。

In any case -- ST or traditional EDSM -- the execution state has to be stored somewhere. Keeping it on the stack is much more efficient than in ad hoc data structures.

不管是 ST 还是传统的EDSM，执行状态都必须存储在某个地方。将其保存在堆栈中要比保存在临时数据结构中更有效率。正如 ASF 的 Dean Gaudet 所写的那样 ....

loken

信 StateThread 官方文章 State Threads for Internet Applications ，很详细地分析了这 4 种架构的情况。

而且他在 FAQ 里面说异步编程，也就是传统的 EDSM 编程模式与 State Threads 协程的性能是一样的。

从CPU角度分析：

Performance-wise ST is as fast as traditional EDSM implementations. The context switch overhead is a cost of doing_setjmp()/_longjmp() (no system calls are involved). This is negligible for all practical applications. The thread creation overhead is also very small.
从性能上看，ST 与传统的 EDSM 实现一样快。上下文切换开销是执行 _setjmp()/_longjmp()的成本(不涉及系统调用)。这在所有实际应用中都可以忽略不计。线程创建开销也非常小

从内存角度分析：

Memory-wise ST is almost as efficient as traditional EDSMs. Although the swap space is reserved for the entire stack segment upon thread creation, only stack pages that are actually used (touched) will be brought into physical memory. There is, however, one page per thread minimum memory requirement. In any case -- ST or traditional EDSM -- the execution state has to be stored somewhere. Keeping it on the stack is much more efficient than in ad hoc data structures. As Dean Gaudet from ASF wrote:
在内存方面，ST 的效率几乎与传统的 EDSM 不相上下。虽然在创建线程时会为整个堆栈段保留交换空间，但只有实际使用 (接触)的堆栈页才会被带入物理内存。不过，每个线程最少需要一页内存。不管是 ST 还是传统的 EDSM，执行状态都必须存储在某个地方。将其保存在堆栈中要比保存在临时数据结构中更有效率。正如 ASF 的 Dean Gaudet 所写的那样

StateThread 官方的这些文章很有价值，为了防止后面下架了，我保存成 PDF 了，可以在百度网盘下载。
链接：https://pan.baidu.com/s/1QsTHzMJ1V0mBQeX7xxbeBg?pwd=mvke
提取码：mvke

信

loken 嗯，总归要有地方记录保存状态的，不管看什么协程源码，直接找 context.s看就行了，上下文切换的原理就在里面

浩锐

ZLMediaKit 的 RTMP 状态机是 _next_step_func，请看下图

下面的代码就是在切换 RTMP 三次握手

浩锐

协程不太了解，不过状态机阅读我觉得实际上不是很复杂。
状态机能够处理不少分支流，用更紧凑的方式
不至于死亡缩进，用多个 if else 和大 while 循环时效件

异步模型近年来感觉其实也比较好了，难读的异步大多数指的是异步+回调的方式吧

如果是类似于 feature 这样子的 prmoise 的异步模型，像 js 中的语法那样，我觉得也挺简单的