ST源码分析-前言

本文主要是介绍ST源码分析-前言，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

SRS 的社群来了，想加入微信社群的朋友请购买《SRS原理》电子书，里有更高级的内容与答疑服务。

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 fdepoll_wait();//处理状态改变的fdrecvfrom(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++ 协程库有以下几个：