ST 是 state-thread 的缩写。state-thread 是一个 C 语言实现的协程库，这个库是 8年前的， 《state-thread 官网文档》。
ST 协程优势有以下几点：
1，从性能上来说，ST和传统的EDSM实现几乎一样快。也就是用 ST 跟用 单线程 epoll 一样高效。
2，在内存方面，ST几乎和传统的EDSM一样高效。也就是用 ST 跟用 epoll 一样高效。
3，因为单线程非阻塞 epoll 的架构 会把 请求 跟 回调 分离，这种 请求 跟 回调 分离 的架构 ，这个架构在复杂业务下可能会导致回调地狱的问题。伪代码如下：
dns_udp_data_1 = {xxx}
sendto(dns_udp_data_1)
dns_udp_data_2 = {xxx}
sendto(dns_udp_data_2)
dns_udp_data_3 = {xxx}
sendto(dns_udp_data_3)
while(){
//等待 3 个udp fd
epoll_wait();
//处理状态改变的fd
recvfrom(fd);
//处理 dns 响应
}从上面的伪代码可以看到，单线程非阻塞如果不用协程，语法上，请求跟 回调 处理是分开的，比较容易的理解语法应该是 一个 sendto 然后一个 recvfrom，处理完一个任务再执行另一个任务。
使用了 state-thread 就可以合并 sendto 跟 recvfrom， st_sendto() 会阻塞在 st_recvfrom()，但并不是真正的阻塞，而是把 fd 丢进去全局管理器之后，就切换到其他协程执行，因此 st_recvfrom() 并不像 操作系统的 recvform() 一样，会阻塞线程的其他任务。在 ST 里面 阻塞 本质上就是切换上下文，当所有协程都执行完，idle协程就会 epoll_wait() 等待 所有fd 的变化，这里才是真正的阻塞。fd 有变化了，再切换回去之前的 st_recvfrom() 继续执行。
这样就能把 请求 ，对面的respond （回调）合在一起，顺序处理，代码看起来是顺序的。这样 实现 RTMP 这种复杂协议，因为是顺序的，所以写起来就比 epoll 简单很多。
但是我客观说一下，协程方案每次 st_sendto() 跟 st_recvfrom() 之后都会经历一次上下文切换，这个上下文切换大概会执行10多条汇编指令。所以协程方案 做多域名DNS查询 比上面的伪代码执行速度是慢一些的，因为上面的伪代码，3 个 sendto 是线性执行，没有上下文切换。
而且多个协程因为是在单线程里面运行的，所以他们并不是并行的，也就是多个协程操作全局变量不用加锁，这是优势，也是劣势。
单线程多协程开了很多协程处理不同的任务的时候，会非常影响实时性。因为如果多个推流协程跟多个播放线程都在一个线程里面，推流协程有数据了，解复用完了处理完了，是不是应该尽快激活播放协程来处理这个数据？但是如果上下文切换到 播放协程来推送数据到客户端，那推流协程就会阻塞停下来，但是推流客户端不是只推一个包，是有源源不断的数据推送来的。而且如果有多个推流客户端 epoll_wait() 不一定激活的第一个fd 就是 播放端的fd，可能是另一个推流客户端的fd，这样实时性会再打折扣。
解决方案可以这样，开一个线程处理多个推流客户端，开另一个线程处理多个播放客户端。线程里面用多协程。
把相同的任务丢进去一个线程，例如推流端，全部丢进去一个线程，播放端放在另一个线程。线程里面都是多协程，这样就能提高实时性。
虽然上面的代码，DNS查询，不用协程，程序会快一些，这是单线程的情况，如果是复杂系统，多线程，不用协程也会导致上下文切换。举个例子，常见的服务器是这样的，线程A 阻塞在 epoll_wait()，另一个线程B 阻塞在条件变量，线程A激活之后，读到信息，激活线程B去处理，这就有可能导致上下文切换，如果两个线程在不同的核心就不会导致切换。但是协程的情况也是这样，epoll_wait() 之后切换上下文，这是协程的切换上下文是自己做的。
所以在复杂系统下，多线程+多协程 VS 多线程回调，我个人认为还是多线程+多协程高明一些，只要把不同的任务分开线程处理，就能并行，提高实时性。比回调写法简单明了很多，因为客户端足够多的时候，两种场景都会有上下文切换的损耗。
如果不用协程，当业务遇到阻塞操作，例如需要查一下数据库，只能阻塞，等查到再继续跑，但是线程池的线程数量是有限的，一个线程阻塞了，要处理更多的请求怎么办？只能再开更多的线程，开更多的线程了，比CPU核数都多了，上下文切换就会更加厉害。最后只能在阻塞时间跟线程数量上做一个权衡。
但是用协程，遇到阻塞操作，就能把协程切走，去执行别的任务。这种协程的创建跟上下文切换，比线程的创建跟上下文切换要廉价很多。
上面说到的查数据库，本身会阻塞线程，除非自己用 st_read 实现一个数据库通信类，如果用操作系统的 read，本身是会阻塞。简单一点可以开另领一个线程专门处理数据库查询，然后业务线程与数据库线程通过 ST 的 fd 进行通信。例如业务线程用 pipe 创建两个fd，read fd 业务线程自己用，数据库线程查询到数据之后写入 write fd，那业务协程就会被激活。业务线程跟数据库线程之间通过管道fd通信。
代码如下：
#include <stdio.h>
#include <pthread.h>
#include <stdlib.h>
#include <unistd.h>
int sig_pipe[2];
//线程执行的函数
void * sql_read(void *args) {
int res;
while (1){
int data = 0;
read(sig_pipe[0],&data,sizeof(data));
printf("read success = %d\n", data);
sleep(2);
printf("sleep 2 \n");
//最终将互斥锁解锁
}
return NULL;
}
//线程执行的函数
void * sql_send(void *args) {
int res;
int data = 5;
write(sig_pipe[1],&data,sizeof(data));
int data2 = 9;
write(sig_pipe[1],&data2,sizeof(data2));
sleep(10);
return NULL;
}
int main() {
pipe(sig_pipe);
int res;
pthread_t mythread1, mythread2;
res = pthread_create(&mythread1, NULL, sql_read, NULL);
if (res != 0) {
printf("mythread1线程创建失败\n");
return 0;
}
res = pthread_create(&mythread2, NULL, sql_send, NULL);
if (res != 0) {
printf("mythread2线程创建失败\n");
return 0;
}
//等待 mythread1 线程执行完成
res = pthread_join(mythread1, NULL);
if (res != 0) {
printf("1：等待线程失败\n");
}
//等待 mythread2 线程执行完成
res = pthread_join(mythread2, NULL);
if (res != 0) {
printf("2：等待线程失败\n");
}
return 0;
}与 state-thread 类似的 C/C++ 协程库有以下几个：
杨成立 在 issue 里面放了几篇 st-thread 库的分析 文章
由于笔者的水平有限， 加之编写的同时还要参与开发工作，文中难免会出现一些错误或者不准确的地方，恳请读者批评指正。如果读者有任何宝贵意见，可以加我微信 Loken1。QQ：2338195090。