技术文章：C语言协程的代码细节

“协程”（coroutine），就是把linux epoll的异步IO机制通过长跳转（long jmp）封装起来，形成一个在用户看来“连续的”流程。

所有操作系统的异步IO，都分为启动函数和回调函数。

以Linux为例，启动函数负责往epoll框架里添加读写事件。

在事件触发之后，再通过回调函数去进行下半部的处理。

整个事件处理过程，与Linux内核里的中断处理差不多。

一个完整的IO流程需要回调好几次，而且读代码时到处查找回调函数在哪里设置的。

甚至，有的程序员会中途修改回调函数的指针[捂脸]

C的函数指针比C++的虚函数更“灵活”的地方是，C++的虚函数表在编译时就固定了，但C的函数指针可以在运行时修改（它就是个普通变量）。

然后，就真有人半截里修改它，让代码的可读性急剧下降。

再然后，就出现了coroutine，看上去至少是同步的了。

程序流程在一个函数里跳转，就是普通的goto语句。

程序流程在2个函数的半截里跳转，就是长跳转（long jmp）。

协程的原理如下：

1，当某个文件描述符需要IO等待的时候，通过长跳转回到epoll的主框架函数，让其他的IO可以运行。

2，当这个文件描述符的IO再次就绪之后，再通过长跳转从主框架函数跳回来，接着上次的位置继续运行：

这个位置，是函数上一次放弃运行的位置，它是函数内的某个点。

 

在函数的半截里放弃CPU之后还能回来，就需要保存函数的运行上下文：栈信息、寄存器信息。

保存到哪里？

只能保存到堆上，因为栈和寄存器都会随着代码的运行而不断地覆盖，只有堆是受用户控制的。

用户测试代码

上图是“用户代码”，虽然两个函数__async_connect()和__async_write()的内部是异步执行的，但它们都在一个函数_async_test()里，整个流程看上去是同步的。

__async_connect()函数，上半部

__async_connect()分为上半部和下半部，以__asm_co_task_yield()为分隔点。

上半部调用异步的connect()，下半部调用getsockopt()读取结果。

为了避免阻塞线程，需要在异步connect()之后让出CPU，让主框架函数可以做别的。

这个让出CPU的函数__asm_co_task_yield()，是“协程库”的关键。

它让出了CPU之后，在事件触发之后再次恢复运行：这时函数__asm_co_task_yield()才会返回，然后接着运行下图的代码。

__async_connect()函数，下半部

当异步connect()成功时，getsockopt()获取的错误码err是0。

__async_write()函数

__async_write()函数的流程与__async_connect()类似，也是在文件描述符变得不可写时放弃CPU，等待下次可写时再恢复运行。

epoll主框架函数

epoll的主框架函数是一个while循环：使用epoll_wait()系统调用去监控事件的触发。

它会同时处理IO事件和定时器。

定时器的精度受限于epoll_wait()的等待时间。

epoll主框架函数

__scf_co_task_run()，可以让“协程任务”首次运行，或者再次恢复运行。

_scf_co_task_run()函数

这个函数只是调用了__asm_co_task_run()，具体的长跳转在汇编里实现。

因为长跳转涉及到细致的内存控制，只能用汇编实现。

运行结果：

要在本机上用命令nc -vv -l 2000当服务端。

 

打印的日志，是长跳转时的栈信息的变化。

两个汇编函数的大概功能，如下面的3张图。

细节就不说了，这种代码，时间久了连作者都快看不懂了[捂脸]