并发编程是什么，进程？线程？其实还有协程，尤其是服务器并发。随着Go的普及，估计大伙儿都知道有协程这个玩意儿了，其实早就有了C里面叫Coroutine，SRS就是用的这个玩意儿。
上图借用的是Kotlin的图，不仅仅是Go，各种的语言都有协程的支持。
协程历史
还是放一张图出来，看看协程的发展历史。
中国文化中，由于历史悠久，所以特别强调继承，如果这个想法是来自远古时代，那才叫真宗。
各位朋友看呐，协程初祖Donald Knuth，60年前的神功秘籍，有啥好怀疑的，赶紧拥抱协程吧，哈哈哈。
SRS的协程
SRS是单进程、单线程、多协程结构，协程(coroutine)背景以后再介绍，这篇文章介绍协程的重要基础，理解了这个基础，后续就容易看懂协程，也能更好的使用协程。
SRS的线程模型，未来会改进成`单进程、多线程、多协程`架构，相关背景和原因请看[#2188](https://github.com/ossrs/srs/issues/2188)。
协程就是用户空间的轻量线程，或者说是用户空间创建的`伪线程`，既然是创建了线程，就需要实现函数调用。简单来说，协程和线程切换的过程是类似的，只不过是用户空间实现的切换：
- _st_md_cxt_save：保存当前函数信息信息到内存，后续可以跳转到这个函数。
- _st_md_cxt_restore：从内存恢复函数的信息，跳转到这个协程。
那么到底需要保存什么信息，又需要恢复哪些信息？这就涉及到了函数是如何调用的，寄存器都用来保存什么信息。
Code
我们写个简单的函数：
// g frame0.cpp -g -O0 -o frame && gdb frame#include <stdio.h>#include <stdlib.h>
int callee(int a, long b) { int c = a; c = (int)b; return c;}
void caller() { int v = callee(10, 20); printf("v=%dn", v);}
int main(int argc, char** argv) { caller(); return 0;}代码可以直接从Docker中获取、编译和调试：
docker run --rm --privileged -it -w /srs/trunk/research/frame ossrs/srs:study cat frame0.cpp
# 国内建议用阿里云的镜像docker run --rm --privileged -it -w /srs/trunk/research/frame registry.cn-hangzhou.aliyuncs.com/ossrs/srs:study cat frame0.cppDocker的使用详细请参考[srs-docker: study](https://github.com/ossrs/srs-docker/tree/study#usage)。
GDB
编译代码，用GDB启动调试：
docker run --rm --privileged -it -w /srs/trunk/research/frame registry.cn-hangzhou.aliyuncs.com/ossrs/srs:study bash -c 'g frame0.cpp -g -O0 -o frame && gdb frame'设置断点在main函数：
(gdb) b main(gdb) run关于常用汇编的GDB指令：
- layout pre：切换到TUI(文本图形模式)，可以多次切换选择不同的layout，可以看到汇编和寄存器。
- CTRL x：快捷键，在TUI和非TUI模式下切换；可以配合`layout pre`使用。
- si：汇编指令单步执行，每次只执行一行汇编。由于一行C代码可能对应多行汇编，所以函数调用时需要看每行汇编的执行。
- p $rax 或 p /x $rax：查看寄存器`rax`的内容。
- x /2xa 0x7ffe490993d8：查看内存块中的指针，以8字节为单元查看。
如下图所示，切换到寄存器模式：
搭建好环境，我们就可以分析执行函数都调用了哪些汇编，寄存器又有什么变化。
函数调用过程
分析caller()调用callee()函数的汇编代码：
0x40058c <caller() 18> callq 0x40055d <callee(int, long)>callq这个指令，自动保存了caller的rip到栈：
# 执行callq之前，栈rsp是$rsp = (void *) 0x7ffe490993e0
# 执行callq这条汇编之后，栈向下移动了8字节：$rsp = (void *) 0x7ffe490993d8
# 可以看到，是将rip值保存到了栈，也就是caller的入口地址：(gdb) x/1xa 0x7ffe490993d80x7ffe490993d8: 0x400591 <caller() 23>进入callee函数时，有两条汇编做了初始化：
# 将rbp，这时候还是caller的rbp放到堆栈0x40055d <callee(int, long)> push %rbp# 将rsp也就是callee函数当前的栈，放入rbp0x40055e <callee(int, long) 1> mov %rsp,%rbp
# 执行后，栈继续向下移动8字节(push指令)，并设置了rbp$rsp = (void *) 0x7ffe490993d0$rbp = (void *) 0x7ffe490993d0此时，栈中就保存了两个重要的信息，就是caller的rip和rbp：
(gdb) x/2xa 0x7ffe490993d00x7ffe490993d0: 0x7ffe490993f0 0x400591 <caller() 23>总结如下图所示：
callee的rbp前两个指针，16字节，就是caller的rip和fp/rbp。
为何要保存这个信息呢？这两个信息实际上就是函数的入口和栈地址，也可以在函数中获取调用堆栈。比如，我们进入callee后，根据这两个信息，可以知道整个调用链：
# 在callee中，查看callee的`rbp`指向的栈的两个指针# rip 0x400591，就是caller的入口# rbp 0x7ffe490993f0，就是caller的rbp(gdb) x/2xa $rbp0x7ffe490993d0: 0x7ffe490993f0 0x400591 <caller() 23>
# 由于知道了caller的rbp，可以继续查看上一层的调用信息：# rip 0x4005be，就是main函数# rbp 0x7ffe49099410，就是main的rbp了(gdb) x/2xa 0x7ffe490993f00x7ffe490993f0: 0x7ffe49099410 0x4005be <main(int, char**) 20>
# 还可以继续查看，最终入口是glibc的这个函数：(gdb) x/2xa 0x7ffe490994100x7ffe49099410: 0x0 0x7f1608e8f555 <__libc_start_main 245>为了方便，还有个`fp`寄存器，一般就等于`rbp`，但是[并非所有都是这么实现]( https://stackoverflow.com/a/47008882 )。
我们在gdb中，一般通过`bt`查看调用堆栈，显示的地址就是`rip`：
(gdb) bt#0 0x000000000040056b in callee (a=10, b=20) at frame0.cpp:9#1 0x0000000000400591 in caller () at frame0.cpp:15#2 0x00000000004005be in main (argc=1, argv=0x7ffec0b642c8) at frame0.cpp:20
(gdb) p $rip$45 = (void (*)(void)) 0x40056b <callee(int, long) 14>
(gdb) x/2xa $rbp0x7ffec0b641a0: 0x7ffec0b641c0 0x400591 <caller() 23>关于参数rdi/rsi/rdx/rcx/r8/r9和返回值rax，我们以另外一个例子说明。
长参数函数调用
下面是一个有很多参数的程序的例子：
docker run --rm --privileged -it -w /srs/trunk/research/frame registry.cn-hangzhou.aliyuncs.com/ossrs/srs:study cat cat frame1.cpp编译代码，用GDB启动调试：
docker run --rm --privileged -it -w /srs/trunk/research/frame registry.cn-hangzhou.aliyuncs.com/ossrs/srs:study bash -c 'g frame1.cpp -g -O0 -o frame && gdb frame'调试后，总结如下图所示：
- 返回值是rax。
- 第一个参数rdi，第二个rsi，第三个是rdx，第四个是rcx，第五个是r8，第六个是r9，再往后就在rsp堆栈往上存储。
了解完这些函数的调用过程，那么对于协程的实现，要保存哪些寄存器，如何恢复寄存器，就比较清楚了。
如果没有看懂，也没关系，多看几遍，多调试下，就懂了。
