“协程”（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张图。
细节就不说了，这种代码，时间久了连作者都快看不懂了[捂脸]
