协程运行时：IO Hook、调度器与汇编上下文切换

Tue, 11 Aug 2026 00:00:00 +0800

本篇承接 yield、resume、ucontext 和简单轮询调度，重点理解阻塞式 I/O 的 Hook、协程状态管理、调度器与 epoll 的协作，以及 x86-64 汇编上下文切换。

一、从上下文切换走向完整协程运行时

已经掌握的两个方向：

main → ctx ：resume
ctx → main ：yield

它们底层都依赖一次 context switch：

保存当前执行现场
 ↓
恢复目标执行现场
 ↓
目标协程从上次暂停位置继续

但只有 switch、resume 和 yield 还不够。真正处理网络 I/O 还需要回答：

1. 普通read/recv没有数据时，怎样自动yield？
2. fd就绪以后，怎样找到并resume对应协程？
3. 十万个协程如何保存和组织？
4. READY、WAITING、SLEEPING、EXITED如何管理？
5. 定时器和I/O超时如何处理？
6. 上下文切换怎样用汇编实现？
7. 多核机器上怎样运行多个调度器？

最终需要形成：

POSIX I/O调用
 ↓
Hook层
 ↓
非阻塞I/O + epoll
 ↓
yield / resume
 ↓
协程状态和调度器
 ↓
ucontext或汇编context switch

二、为什么需要 Hook I/O

一个协程中的业务代码希望保持顺序结构：

while(1){
recv();
parser();
send();
}

阅读时仍然是：

接收数据
 ↓
解析数据
 ↓
发送响应

但如果这里直接调用阻塞式 recv()，没有数据时会阻塞整个线程，线程内其他协程也无法运行。

协程库希望在不大改业务流程的情况下，把调用替换为自己的实现：

业务调用recv/read
 ↓
进入协程库Hook函数
 ↓
先尝试非阻塞I/O
 ├── 已就绪：调用真实系统函数并返回
 └── 未就绪：注册epoll事件并yield
 ↓
 fd就绪
 ↓
 resume协程
 ↓
 再调用真实系统函数

这就是：

上层保持同步代码结构，底层通过 epoll 和协程实现异步等待。

三、Hook 的概念流程

笔记中的伪代码：

recv（fd,buffer,length）{
struct pollfd fds[1]={0};
fds[0].fd=fd;
if(0<poll(fd,1,0)){//io可读
recv_f(fd,buffer,length);
}else{
epoll_ctl(epfd,EPOLL_CTL_ADD,fd,&ev);
swapcontext();

}
}

它表达了四步。

3.1 检查 fd 是否就绪

poll(fd,1,0)

timeout 为 0，表示立即检查，不在 poll() 中等待。

返回值 > 0 → 当前fd有事件
返回值 = 0 → 当前没有事件
返回值 < 0 → 调用发生错误

3.2 已就绪时调用真实函数

recv_f(fd,buffer,length);

recv_f 指向真正的系统 recv，而不是 Hook 后的同名函数。

3.3 未就绪时注册 epoll

epoll_ctl(epfd,EPOLL_CTL_ADD,fd,&ev);

同时记录：

哪个fd
等待什么事件
哪个协程正在等待它
是否存在超时时间

3.4 当前协程 yield

swapcontext();

这里代表概念上的 yield。实际实现需要明确传入当前协程上下文和调度器上下文。

当前协程WAITING
 ↓
yield回调度器
 ↓
调度器运行其他READY协程

四、使用 dlsym 拦截 read 和 write

以下是提供的 Hook 代码：

#define _GNU_SOURCE

#include <dlfcn.h>

#include <stdio.h>
#include <ucontext.h>
#include <string.h>
#include <unistd.h>
#include <fcntl.h>

#include <sys/socket.h>
#include <errno.h>
#include <netinet/in.h>


#include <pthread.h>
#include <sys/poll.h>
#include <sys/epoll.h>

4.1 为什么需要 _GNU_SOURCE

#define _GNU_SOURCE

它在包含系统头文件前启用 GNU 扩展声明，使 dlsym()、RTLD_NEXT 等接口在相应环境中可见。

4.2 函数指针类型

原代码：

typedef ssize_t (*read_t)(int fd, void *buf, size_t count);
read_t read_f = NULL;

typedef ssize_t (*write_t)(int fd, const void *buf, size_t count);
write_t write_f = NULL;

read_t 描述真实 read() 的函数类型：

参数1：fd
参数2：接收缓冲区
参数3：最大读取长度
返回值：实际读取长度或错误

write_t 对应真实 write()。

read_f → 保存原始read地址
write_f → 保存原始write地址

五、init_hook() 如何取得真实函数

原代码：

void init_hook(void) {

	if (!read_f) {
		read_f = dlsym(RTLD_NEXT, "read");
	}

	
	if (!write_f) {
		write_f = dlsym(RTLD_NEXT, "write");
	}

}

dlsym() 根据符号名查找函数地址：

dlsym(RTLD_NEXT, "read");

RTLD_NEXT 的含义可以理解为：

从当前 Hook 定义之后继续寻找下一个名为 read 的实现。

因此调用关系是：

业务代码调用read()
 ↓
进入当前文件定义的Hook read()
 ↓
Hook内部调用read_f()
 ↓
进入真正的系统read()

如果 Hook 内部再次直接调用 read()：

Hook read()
 ↓
又进入Hook read()
 ↓
无限递归

所以必须使用 read_f 调用真实函数。

使用 dlsym() 时通常需要链接动态加载库：

gcc ... -ldl

六、read() Hook 的执行过程

原代码：

ssize_t read(int fd, void *buf, size_t count) {

	struct pollfd fds[1] = {0};

	fds[0].fd = fd;
	fds[0].events = POLLIN;

	int res = poll(fds, 1, 0);
	if (res <= 0) { //不可读


		// fd --> epoll_ctl();

		swapcontext(); // fd --> ctx fd与context一对一
		
	}
	// io

	
	ssize_t ret = read_f(fd, buf, count);
	printf("read: %s\n", (char *)buf);
	return ret;

	
	
}

6.1 构造 pollfd

struct pollfd fds[1] = {0};

fds[0].fd = fd;
fds[0].events = POLLIN;

表示只检查一个 fd 的可读事件。

6.2 立即检查

int res = poll(fds, 1, 0);

第三个参数为 0：

不等待
立即返回当前状态

6.3 不可读时暂停协程

if (res <= 0) {
 // fd --> epoll_ctl();
 swapcontext();
}

完整运行时还需要在 yield 前完成：

将fd设置为非阻塞
将fd注册到epoll
记录fd等待POLLIN/EPOLLIN
记录当前等待协程
设置可选超时时间
当前协程状态改为WAITING
yield到scheduler

fd 就绪后：

epoll_wait返回fd
 ↓
找到等待它的协程
 ↓
协程进入READY队列
 ↓
scheduler resume协程
 ↓
从swapcontext()之后继续
 ↓
read_f()真正读取数据

6.4 调用真实 read

ssize_t ret = read_f(fd, buf, count);

这一步才真正从内核读取数据。

poll 告诉程序“当前可能可读”，read_f 才完成实际读取。就绪状态可能在检查和读取之间变化，因此 fd 仍然应该是非阻塞的，并正确处理 EAGAIN。

七、write() Hook

原代码：

ssize_t write(int fd, const void *buf, size_t count) {

	printf("write: %s\n", (const char *)buf);

	return write_f(fd, buf, count);
}

当前实现主要展示：

业务调用write
 ↓
进入Hook write
 ↓
调用write_f进入真实write

完整协程版 write() 也需要处理：

真实write成功一部分
 → 记录已写偏移，继续写剩余数据

真实write返回EAGAIN
 → 注册EPOLLOUT
 → 当前协程yield
 → fd可写后resume

Hook write() 内部使用 printf() 记录日志时要特别小心，因为 printf() 最终也可能调用 write()，从而再次进入 Hook。实际实现通常使用不会再次触发该 Hook 的日志路径，或者直接调用保存下来的真实 write_f。

八、Hook 示例怎样接入普通服务端

原代码：

int main() {

	init_hook();

	int sockfd = socket(AF_INET, SOCK_STREAM, 0);

	struct sockaddr_in serveraddr;
	memset(&serveraddr, 0, sizeof(struct sockaddr_in));

	serveraddr.sin_family = AF_INET;
	serveraddr.sin_addr.s_addr = htonl(INADDR_ANY);
	serveraddr.sin_port = htons(2048);

	if (-1 == bind(sockfd, (struct sockaddr*)&serveraddr, sizeof(struct sockaddr))) {
		perror("bind");
		return -1;
	}

	listen(sockfd, 10);

	struct sockaddr_in clientaddr;
	socklen_t len = sizeof(clientaddr);
	int clientfd = accept(sockfd, (struct sockaddr*)&clientaddr, &len);
	printf("accept\n");

	while (1) {

		char buffer[128] = {0};
		int count = read(clientfd, buffer, 128);
		if (count == 0) {
			break;
		}
		write(clientfd, buffer, count);
		printf("sockfd: %d, clientfd: %d, count: %d, buffer: %s\n", sockfd, clientfd, count, buffer);

	}

	return 0;

}

业务代码仍然调用：

read(clientfd, buffer, 128);
write(clientfd, buffer, count);

但由于程序中定义了同名 read() 和 write()，符号解析会先进入 Hook。

这正是 Hook 的价值：

业务代码结构保持不变
 ↓
read/write调用被协程库接管
 ↓
等待I/O时自动yield
 ↓
就绪后自动resume

当前示例只接收一个 clientfd，重点是展示 Hook 链路。与真正协程服务器结合时，还需要 accept Hook、多连接协程、epoll mainloop 和 scheduler。

九、为什么第三方库也可以受益

例如本地程序使用 hiredis 连接 Redis。hiredis 内部会调用 read/write 或 send/recv 完成网络操作。

不修改 hiredis 源码时：

业务调用hiredis
 ↓
hiredis内部调用read/write
 ↓
进入协程库Hook
 ↓
没有数据时yield
 ↓
Redis响应到达后resume

因此原本按照阻塞式 POSIX API 编写的库，有机会直接运行在协程调度环境中。

前提是 Hook 覆盖了它实际调用的 API，并正确处理：

阻塞标志
超时
EINTR
EAGAIN
部分读写
close和fd复用
线程安全

十、如何定义一个协程

笔记中的初始设计：

struct coroutinue{
int fd;
ucontext_t ctx;//stack ，stack_size,func包含在里面
void *arg

};

一个协程需要保存两类信息。

10.1 执行现场

ctx → 寄存器、栈指针、执行位置等上下文
stack → 协程自己的栈
stack_size → 栈大小
entry → 协程入口函数
arg → 入口参数

10.2 调度状态

id → 协程标识
state → READY、RUNNING、WAITING等
fd → 当前等待的I/O对象
events → 等待EPOLLIN或EPOLLOUT
expire_at → 超时时间或唤醒时间
scheduler → 所属调度器

概念上的完整结构：

struct coroutine
 ├── id
 ├── state
 ├── context
 ├── stack / stack_size
 ├── entry / arg
 ├── waiting_fd / events
 ├── expire_at
 ├── ready_node
 ├── wait_node
 ├── sleep_node
 └── scheduler

本篇沿用原笔记中的 coroutinue 拼写来对应代码，实际项目中可以统一为 coroutine。

十一、协程入口与创建

原始设计：

void func(void){

}


typedef void *(*coroutinue_entry)(void *)
int create_coroutinue(co_id id,coroutinue_entry entry,void *arg){
struct coroutinue *co =malloc(sizeof(struct coroutinue));
co.ss_sp=
makecontext(co->ctx,func,0);
}

创建协程需要完成：

1. 分配struct coroutine
2. 分配或绑定独立栈
3. 保存entry和arg
4. 初始化context
5. 设置入口包装函数
6. 设置协程退出后的返回目标
7. state设为READY
8. 加入ready_queue

为什么通常需要一个入口包装函数：

scheduler resume新协程
 ↓
进入wrapper
 ↓
wrapper调用entry(arg)
 ↓
entry返回
 ↓
wrapper把协程状态设为EXITED
 ↓
yield回scheduler
 ↓
scheduler回收资源

如果直接让入口函数随意 return，而没有统一退出路径，调度器很难正确修改状态和释放栈。

十二、十万个协程如何组织

假设采用“一连接一协程”：

10万个fd
 ↓
10万个coroutine对象

但它们不会全部同时运行。

例如：

10万个协程
 ├── 2万个READY
 ├── 5万个WAITING
 ├── 2万个SLEEPING
 └── 1万个已结束或待回收

调度器必须按状态组织它们，不能每轮扫描全部十万个对象。

十三、READY 为什么使用队列

笔记中的设计：

queue_node (corountine,)ready_queue

READY 协程表示现在就可以运行。

常见操作：

协程变为READY → 从队尾加入
scheduler取任务 → 从队头取出
协程yield但仍可运行 → 再放回队尾

因此队列适合：

O(1)入队
O(1)出队
天然支持轮询公平调度

如果有 2 万个 READY 协程：

ready_head
 → co1 → co2 → co3 → ... → co20000

scheduler 每次取队头协程 resume。

十四、WAITING 与 SLEEPING 为什么需要有序结构

笔记中的设计：

rbtree_node(coroutinue,)wait_rb;
rbtree_node(coroutinue,)sleep_rb;

等待 I/O 的协程可能还设置超时：

协程A等待fd=4，100ms后超时
协程B等待fd=5，500ms后超时
协程C等待fd=6，50ms后超时

睡眠协程也有不同唤醒时间：

协程D睡眠到10:00:00.100
协程E睡眠到10:00:00.800

如果以 expire_at 为 key 放入有序结构，调度器可以快速找到最早到期节点：

最小expire_at
 ↓
与当前时间比较
 ↓
已经到期就移出
 ↓
状态改为READY
 ↓
加入ready_queue

红黑树、最小堆、跳表、时间轮都可以实现定时管理，具体选择取决于插入、删除、精度和规模要求。

I/O fd 到协程的查找，还可以另外使用：

epoll_event.data.ptr
哈希表 fd → coroutine
数组 fd → coroutine

时间树解决“谁先超时”，fd 映射解决“哪个事件唤醒谁”，它们是两个不同查找维度。

十五、一个协程为什么可以同时拥有多个节点

笔记中的思路是把数据结构节点直接放进 coroutine：

ready_node
wait_node
sleep_node

这种方式称为侵入式数据结构：

coroutine对象本身包含链表节点或树节点
 ↓
不需要额外分配包装节点
 ↓
从节点可以找回所属coroutine

但协程状态必须保持一致：

READY → 位于ready_queue
WAITING → 位于I/O等待集合，可能同时位于超时树
SLEEPING → 位于sleep定时结构
RUNNING → 当前正在执行，通常不在ready_queue
EXITED → 位于回收集合或等待立即回收

协程从一个状态切到另一个状态时，需要从旧集合移除，再加入新集合，避免同一个节点被重复挂载。

十六、scheduler 如何定义

笔记中的设计：

scheduler
struct scheduler{
int epfd
struct epoll_event events[];

queue_node (corountine,)ready_head
rbtree_root(coroutinue,)wait_rb;
rbtree_root(coroutinue,)sleep_rb;

};

各字段含义：

epfd → epoll实例
events[] → epoll_wait返回的就绪事件
ready_head → 当前可以运行的协程
wait_rb → 等待I/O并带超时的协程
sleep_rb → 主动睡眠的协程

完整调度器还会需要：

main_context → scheduler自己的上下文
current → 当前正在运行的协程
all_coroutines → 所有协程的所有权集合
exited_queue → 等待回收的协程
stop → 退出标志
thread_id → 所属线程

十七、哪些操作由协程执行，哪些由调度器执行

17.1 协程主动执行

调用read/recv/send/write
发现需要等待后yield
主动sleep
业务处理
入口函数返回并exit

17.2 调度器执行

维护ready_queue
计算最近超时时间
调用epoll_wait
处理fd就绪事件
处理wait/sleep超时
把协程转为READY
选择下一个协程resume
回收EXITED协程

核心边界：

协程表达“我要等待什么”，调度器决定“等待期间运行谁，以及何时唤醒我”。

十八、调度循环的完整流程

一个合理的 scheduler mainloop 可以概括为：

while没有停止：

 1. 处理已经到期的sleep节点
 2. 处理已经超时的I/O等待节点
 3. 处理ready_queue中的协程
 4. 根据最近定时器计算epoll_wait超时
 5. 调用epoll_wait
 6. 根据events找到等待协程
 7. 将就绪协程加入ready_queue
 8. 回收已经退出的协程

如果 ready_queue 非空：

可以先继续运行READY协程
epoll_wait使用timeout=0避免阻塞

如果 ready_queue 为空：

根据最近timer计算等待时间
 ↓
epoll_wait可以阻塞到I/O到达或定时器到期

这样线程不会忙等。

十九、协程状态怎样流转

典型状态：

NEW
 ↓ create
READY
 ↓ scheduler resume
RUNNING
 ├── 等待I/O → WAITING
 ├── sleep → SLEEPING
 ├── 主动yield且仍可运行 → READY
 └── entry返回 → EXITED

WAITING
 ├── fd就绪 → READY
 └── 超时 → READY，并携带timeout结果

SLEEPING
 └── 时间到 → READY

EXITED
 ↓ scheduler回收
DESTROYED

状态与容器必须同步：

state = READY
 ↔ 在ready_queue中

state = WAITING
 ↔ 在I/O等待映射中

state = SLEEPING
 ↔ 在timer结构中

二十、setjmp、ucontext 和汇编怎样选择

三种方案：

setjmp / longjmp
ucontext
architecture-specific assembly

20.1 setjmp / longjmp

优点：

标准C接口
可移植性相对好
适合理解保存点和恢复点

限制：

不直接提供独立协程栈管理
构造完整栈式协程较复杂

20.2 ucontext

优点：

getcontext/makecontext/swapcontext语义清晰
可以直接指定独立栈和入口函数
教学和原型实现简单

限制：

已经不属于现代POSIX标准
不同平台支持情况不一致

20.3 汇编

优点：

直接控制保存和恢复的寄存器
切换路径短
适合性能敏感的运行时

限制：

与CPU架构、ABI和调用约定绑定
x86-64、ARM64等需要不同实现
测试和维护成本高

性能不能只靠固定排名判断，需要在相同编译器、架构和切换模型下基准测试。汇编通常能做得更精简，但正确性和可移植性同样重要。

二十一、x86-64 汇编上下文切换原代码

#elif defined(__x86_64__)

__asm__ (
" .text \n"
" .p2align 4,,15 \n"
".globl _switch \n"
".globl __switch \n"
"_switch: \n"
"__switch: \n"
" movq %rsp, 0(%rsi) # save stack_pointer \n"
" movq %rbp, 8(%rsi) # save frame_pointer \n"
" movq (%rsp), %rax # save insn_pointer \n"
" movq %rax, 16(%rsi) \n"
" movq %rbx, 24(%rsi) # save rbx,r12-r15 \n"
" movq %r12, 32(%rsi) \n"
" movq %r13, 40(%rsi) \n"
" movq %r14, 48(%rsi) \n"
" movq %r15, 56(%rsi) \n"
" movq 56(%rdi), %r15 \n"
" movq 48(%rdi), %r14 \n"
" movq 40(%rdi), %r13 # restore rbx,r12-r15 \n"
" movq 32(%rdi), %r12 \n"
" movq 24(%rdi), %rbx \n"
" movq 8(%rdi), %rbp # restore frame_pointer \n"
" movq 0(%rdi), %rsp # restore stack_pointer \n"
" movq 16(%rdi), %rax # restore insn_pointer \n"
" movq %rax, (%rsp) \n"
" ret \n"
);
#endif

对应的上下文结构：

typedef struct _nty_cpu_ctx {
	void *esp; //
	void *ebp;
	void *eip;
	void *edi;
	void *esi;
	void *ebx;
	void *r1;
	void *r2;
	void *r3;
	void *r4;
	void *r5;
} nty_cpu_ctx;



int _switch(nty_cpu_ctx *new_ctx, nty_cpu_ctx *cur_ctx);

函数语义：

new_ctx → 即将恢复的目标上下文
cur_ctx → 当前需要保存的上下文

在 System V AMD64 ABI 中，前两个整数或指针参数通常放在：

第一个参数new_ctx → RDI
第二个参数cur_ctx → RSI

因此：

RSI作为基地址 → 保存当前上下文
RDI作为基地址 → 加载目标上下文

二十二、汇编第一部分：保存当前上下文

22.1 保存栈指针

movq %rsp, 0(%rsi)

含义：

把当前RSP保存到cur_ctx偏移0的位置

RSP 指向当前线程正在使用的栈顶。恢复 RSP 才能回到该协程自己的栈。

22.2 保存帧指针

movq %rbp, 8(%rsi)

一个指针占 8 字节，所以第二个字段位于偏移 8。

22.3 保存返回地址

movq (%rsp), %rax
movq %rax, 16(%rsi)

调用 _switch 时，返回地址位于当前栈顶。先读到 RAX，再保存到 cur_ctx 偏移 16。

这个地址就是以后恢复协程时需要继续执行的位置。

22.4 保存被调用者保存寄存器

movq %rbx, 24(%rsi)
movq %r12, 32(%rsi)
movq %r13, 40(%rsi)
movq %r14, 48(%rsi)
movq %r15, 56(%rsi)

这些寄存器按照 x86-64 System V ABI 属于 callee-saved registers。函数返回后调用方有权期待它们保持不变，因此 context switch 必须保存和恢复。

偏移每次增加 8：

0 → rsp
8 → rbp
16 → rip/返回地址
24 → rbx
32 → r12
40 → r13
48 → r14
56 → r15

原结构中的 esp、ebp、eip 是 32 位风格名称；在这段 x86-64 汇编中实际保存的是 rsp、rbp 和返回地址。

二十三、汇编第二部分：恢复目标上下文

movq 56(%rdi), %r15
movq 48(%rdi), %r14
movq 40(%rdi), %r13
movq 32(%rdi), %r12
movq 24(%rdi), %rbx
movq 8(%rdi), %rbp
movq 0(%rdi), %rsp
movq 16(%rdi), %rax
movq %rax, (%rsp)
ret

这部分按相反方向加载 new_ctx：

恢复r15、r14、r13、r12、rbx
 ↓
恢复rbp
 ↓
恢复目标协程rsp
 ↓
把目标返回地址放到目标栈顶
 ↓
ret弹出返回地址
 ↓
从目标协程保存位置继续执行

最关键的一步：

movq 0(%rdi), %rsp

RSP 一旦切换，当前使用的栈就从旧协程栈变成了目标协程栈。

最后：

ret

从目标栈弹出保存的指令地址，于是代码看起来像目标协程之前调用的 _switch() 正常返回。

二十四、为什么不是保存所有寄存器

x86-64 有更多通用寄存器，但按照函数调用约定分为：

caller-saved → 调用方负责在需要时保存
callee-saved → 被调用函数必须保证返回后不变

_switch() 以普通函数调用形式进入，编译器会按照 ABI 处理 caller-saved 寄存器中的临时值，因此最小切换实现主要保存 callee-saved 寄存器、栈指针和返回位置。

这依赖：

明确的ABI
正确的函数声明
编译器遵循调用约定
汇编与结构体布局完全一致

System V AMD64 中，前六个整数或指针参数通常依次使用：

RDI、RSI、RDX、RCX、R8、R9

函数并不是不能超过六个参数。超过六个的参数会按照 ABI 放到栈上，只是调用方式不再全部使用参数寄存器。

二十五、从 Hook read 到调度器唤醒的完整链路

协程A调用read(fd)
 ↓
进入Hook read
 ↓
poll或真实read发现暂时不可读
 ↓
fd注册EPOLLIN
 ↓
记录fd → 协程A
 ↓
协程A状态RUNNING → WAITING
 ↓
_switch(scheduler_ctx, coA_ctx)
 ↓
scheduler运行其他READY协程
 ↓
epoll_wait返回fd
 ↓
根据event找到协程A
 ↓
从等待集合删除协程A
 ↓
协程A状态WAITING → READY
 ↓
加入ready_queue
 ↓
scheduler选择协程A
 ↓
_switch(coA_ctx, scheduler_ctx)
 ↓
协程A从Hook read中的yield位置继续
 ↓
调用read_f真正读取
 ↓
返回业务代码

这一整条链路把四个模块连接起来：

Hook层
epoll事件层
scheduler调度层
context switch底层

二十六、多线程与多进程模式

26.1 多线程模式

一种设计是多个线程各自运行调度器：

线程1 → scheduler1 → epoll1 → 一组协程
线程2 → scheduler2 → epoll2 → 一组协程
线程3 → scheduler3 → epoll3 → 一组协程

这通常比多个线程共同操作一个 scheduler 更容易控制，因为每个协程和上下文固定属于一个线程。

如果多个线程共享：

ready_queue
wait tree
sleep tree
coroutine对象

就需要考虑锁、并发状态迁移、跨线程唤醒和缓存竞争。

CPU affinity 可以让调度线程尽量固定在某个 CPU 核，减少迁移和缓存失效，但是否绑定需要通过测试决定。

26.2 多进程模式

进程1 → scheduler1 → 一组连接
进程2 → scheduler2 → 一组连接
进程3 → scheduler3 → 一组连接

每个进程拥有独立地址空间和调度器，协程数据天然隔离，减少共享锁。

需要额外考虑：

监听端口如何共享
连接如何负载均衡
进程间通信
共享状态
进程崩溃恢复

多线程和多进程都能利用多核。区别主要在共享内存、隔离性和通信成本。

二十七、怎样把协程能力用到实际项目

27.1 网络框架

以 ntyco 为基础理解：

coroutine
scheduler
epoll
Hook
timer
assembly switch

重点不是只复现 switch，而是打通：

I/O等待 → yield → epoll唤醒 → ready → resume

27.2 WebServer

一个连接或请求由一个协程处理
 ↓
协程recv HTTP请求
 ↓
解析协议
 ↓
查询Redis/MySQL
 ↓
发送HTTP响应

每个等待点都由 Hook 和 scheduler 自动让出。

27.3 KV 存储

例如 dkvstore：

连接协程
 ↓
接收命令
 ↓
解析SET/GET
 ↓
访问存储结构
 ↓
返回结果

27.4 图床

上传连接
 ↓
接收文件数据
 ↓
写磁盘或对象存储
 ↓
写数据库
 ↓
返回图片URL

这些项目能够体现的不是“使用了协程”一句话，而是：

怎样Hook阻塞API
怎样管理十万连接状态
怎样设计ready/wait/sleep结构
怎样处理超时和部分读写
怎样在多核上部署调度器
怎样测试切换和网络性能

二十八、核心总结

重点一：Hook 让同步代码接入异步调度

业务仍然调用read/write
 ↓
Hook判断I/O状态
 ↓
不可用时注册epoll并yield
 ↓
就绪后resume

重点二：协程对象既保存执行现场，也保存调度状态

context/stack → 回来后从哪里继续
state/fd/time → 什么时候可以回来
data nodes → 当前属于哪个调度集合

重点三：不同状态需要不同数据结构

READY → queue
I/O映射 → epoll data、数组或哈希
超时/睡眠 → 红黑树、最小堆或时间轮
EXITED → 回收队列

重点四：scheduler 是整个运行时的中心

处理epoll事件
处理定时器
维护协程状态
选择READY协程
执行resume
接收yield
回收退出协程

重点五：汇编 switch 只做保存和恢复

RSI → 保存当前上下文
RDI → 恢复目标上下文
RSP → 切换协程栈
ret → 跳回目标协程保存位置

最终可以把协程运行时理解成：

Hook 决定何时等待，epoll 决定何时就绪，scheduler 决定运行谁，context switch 决定怎样切过去。

汇编 on JasperSao的博客

协程运行时：IO Hook、调度器与汇编上下文切换

一、从上下文切换走向完整协程运行时

二、为什么需要 Hook I/O

三、Hook 的概念流程

3.1 检查 fd 是否就绪

3.2 已就绪时调用真实函数

3.3 未就绪时注册 epoll

3.4 当前协程 yield

四、使用 dlsym 拦截 read 和 write

4.1 为什么需要 _GNU_SOURCE

4.2 函数指针类型

五、init_hook() 如何取得真实函数

六、read() Hook 的执行过程

6.1 构造 pollfd

6.2 立即检查

6.3 不可读时暂停协程

6.4 调用真实 read

七、write() Hook

八、Hook 示例怎样接入普通服务端

九、为什么第三方库也可以受益

十、如何定义一个协程

10.1 执行现场

10.2 调度状态

十一、协程入口与创建

十二、十万个协程如何组织

十三、READY 为什么使用队列

十四、WAITING 与 SLEEPING 为什么需要有序结构

十五、一个协程为什么可以同时拥有多个节点

十六、scheduler 如何定义

十七、哪些操作由协程执行，哪些由调度器执行

17.1 协程主动执行

17.2 调度器执行

十八、调度循环的完整流程

十九、协程状态怎样流转

二十、setjmp、ucontext 和汇编怎样选择

20.1 setjmp / longjmp

20.2 ucontext

20.3 汇编

二十一、x86-64 汇编上下文切换原代码

二十二、汇编第一部分：保存当前上下文

22.1 保存栈指针

22.2 保存帧指针

22.3 保存返回地址

22.4 保存被调用者保存寄存器

二十三、汇编第二部分：恢复目标上下文

二十四、为什么不是保存所有寄存器

二十五、从 Hook read 到调度器唤醒的完整链路

二十六、多线程与多进程模式

26.1 多线程模式

26.2 多进程模式

二十七、怎样把协程能力用到实际项目

27.1 网络框架

27.2 WebServer

27.3 KV 存储

27.4 图床

二十八、核心总结

重点一：Hook 让同步代码接入异步调度

重点二：协程对象既保存执行现场，也保存调度状态

重点三：不同状态需要不同数据结构

重点四：scheduler 是整个运行时的中心

重点五：汇编 switch 只做保存和恢复