[linux][statethread]协程库ST技术分析

前言： 在IO密集型的场景下，尤其是互联网后台，经常会使用epoll等IO复用技术。鉴于直接使用epoll的代码阅读性和开发效率等原因，就抽象出来了各种高级模型。 既然多次提到过协程，那就选择statethread做一下技术分析吧。 基本原理： 1，用户态的IO复用机制支持：select/epoll（这里只针对Linux，其他OS不讨论）。 2，用户态的subroutine切换机制：使用setjmp/longjmp来切换context。 3，O（logn）的高效排序算法：st使用heap排序。

代码分析： 代码：https://sourceforge.net/projects/state-threads/ 1，核心数据结构：

大部分变量的解释，在注释中都解释的比较清晰。其中context字段就是setjmp/longjmp的参数；left/right字段是在heap中使用的；stack字段就是各个thread的栈。

作者猜测是virtual processor的缩写，这里负责用户态的协程调度。其中sleep_q下面重点解读。 2，stack

为了快速分配stack（stack是一段连续内存，默认大小是64K，并且要求地址以page大小对齐），st维护了一个链表_st_free_stacks。默认先从_st_free_stacks中分配，如果分配不到，则使用_st_new_stk_segment（使用mmap匿名映射）从系统中分配；回收stack内存，只是把stack插入到_st_free_stacks中，并不是真正的归还给kernel，所以，会看到使用st的进程/proc/pid/maps中会有大量的内存段，但是这不是memory leak；建议在编译的时候，打开debug选项，可以在stack上下放置一个不可读、不可写、不可运行的page（例如下图中7f4cb82ac000-7f4cb82ae000 ---p 00000000 00:00 0 ），如果栈发生了overflow，会引发segmentation fault（例如协程运行在7f4cb82ae000-7f4cb82be000 rwxp 00000000 00:00 0，如果overflow，就会写入到上面的page中），便于解决问题。如果处理的数据比较大，不建议在栈上使用大量的内存，使用malloc分配就好。

3，timeout heap 使用st的默认前提是IO密集，而一般来说，网络IO都是发送请求-等待回复的过程。那么在等待回复期间，一般都是让当前协程睡眠，切换到其他协程执行。如果都在等待，那就执行idle。那么，问题是执行idle多长时间呢？答案是最近超时的那个！期间后端回包就处理，不回包就处理超时逻辑。根据超时时间，把当前睡眠的协程组织在一个heap上，这就是timeout heap（主要实现在sched.c中）。

due即thread的超时时间，根据due来计算，并把thread插入到heap中。关于st_sleep（sync.c）的实现，很简单，就是把thread的状态改成sleeping，然后插入到heap中。 4，io 主要实现在io.c中，以st_read为例：

先尝试读取，读取不到就执行st_netfd_poll（这里的fd，已经被设置成NONBLOCK类型的）。注意，参数是POLLIN。 st_netfd_poll会继续调用st_poll：

主要逻辑：把当前的thread进入到sleep queue中，就是说，把当前thread根据timeout，加入到timeout heap中；再做_ST_SWITCH_CONTEXT。 5，switch context st支持使用glibc的setjmp/longjmp机制，或者由st自己实现的jmp。由编译选项MD_USE_BUILTIN_SETJMP和USE_LIBC_SETJMP共同控制。看需求，用户自己选择。 6，注意点 st是不支持抢占的！！！换句话说，任何一个协程不主动让渡，那么其他协程永远不能执行。所以注意使用场景。另外，任何一个协程让进程陷入S状态（即ps aux见到的S状态---内核级sleep），其他协程都不能得到执行！！不可以使用sleep，应该用st_sleep；不可以使用read，应该用st_read。。。 后记： 作者尝试过使用st，做更高级别的抽象，用以提高开发效率。最后的验证结果还算满意，性能很不错（比某鹅的xx框架略好一点O(∩_∩)O~）。只是鉴于当时too young，too simple，导致API不够好用。 开开心心撸代码，高高兴兴过大年。