协程 on JasperSao的博客

KV 存储项目网络层：统一接入 Reactor、Proactor 与协程

Sat, 22 Aug 2026 00:00:00 +0800

阅读目标：先恢复项目的整体认识，再通过带注释的代码块回忆具体实现。

本文只解析现有成品代码，不讨论修改方案。ntyco 只讲如何作为 KV 项目的网络层使用。

1. 先恢复项目的整体画面

这个项目的核心不是分别写了三个独立服务器，而是让三个网络服务器共同使用同一个 KV 协议入口：

 kvstore.c
 main + kvs_protocol
 │
 msg_handler 回调
 │
 ┌──────────────┼──────────────┐
 │ │ │
 reactor.c ntyco.c proactor.c
 epoll 协程 io_uring
 │ │ │
 └──────────────┼──────────────┘
 │
 TCP

三种网络层只负责连接和收发，kvs_protocol() 负责处理消息：

客户端请求
 ↓
网络层收到 msg 和 length
 ↓
kvs_protocol(msg, length, response)
 ↓
返回 response 的长度
 ↓
网络层发送 response

项目目前的 kvs_protocol() 是 echo 协议：把请求复制成响应。这一实现展示的重点，是三种网络模型如何接入同一个 KV 协议回调。

六份文件分成三组：

公共入口与接口
 ├─ kvstore.c
 └─ kvstore.h

Reactor 公共连接定义
 └─ server.h

三种网络层
 ├─ reactor.c
 ├─ proactor.c
 └─ ntyco.c

2. 公共入口：`kvstore.h` 与 `kvstore.c`

2.1 `kvstore.h`：把三种网络层统一成一种调用方式

#ifndef KV_STORE_H
#define KV_STORE_H

/* 三种网络实现的编号，供 NETWORK_SELECT 选择 */
#define NETWORK_REACTOR 0
#define NETWORK_PROACTOR 1
#define NET_WORK_NTYCO 2

/* 当前编译使用 io_uring Proactor 网络层 */
#define NETWORK_SELECT NETWORK_PROACTOR

/*
 * KV 协议回调类型：
 * msg 网络层收到的请求
 * length 请求的实际长度
 * response 协议层写入响应的位置
 * 返回值 网络层需要发送的响应长度
 */
typedef int (*msg_handler)(char *msg, int length, char *response);

/* 三种网络层向 kvstore.c 暴露相同形式的启动函数 */
extern int reactor_start(unsigned short port, msg_handler handler);
extern int ntyco_start(unsigned short port, msg_handler handler);
extern int proactor_start(unsigned short port, msg_handler handler);

/* KV 项目支持的命令名称 */
const char *command[] = {
 "SET", "GET", "DEL", "MOD", "EXIST"
};

/* 响应字符串表，目前未填充 */
const char *response[] = {
};

#endif

这一文件的整体作用可以概括为：

NETWORK_SELECT 决定使用谁
msg_handler 规定协议函数长什么样
三个 start 规定网络层怎样启动
command 列出 KV 命令集合

2.2 `kvstore.c`：选择网络层，并把协议函数交给它

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include "kvstore.h"

/*
 * 当前是 echo 形式的 KV 协议入口。
 * 网络层把请求传进来，本函数把请求复制成响应。
 */
int kvs_protocol(char *msg, int length, char *response) {
 /* 输出本次请求长度与内容 */
 printf("recv: %d: %s\n", length, msg);

 /* 将收到的 length 个字节复制到响应缓冲区 */
 memcpy(response, msg, length);

 /* 把响应长度交还给网络层 */
 return strlen(response);
}

int main(int argc, char *argv[]) {
 /* 启动形式要求为：./kvstore <port> */
 if (argc != 2) return -1;

 /* 将命令行中的端口字符串转换成整数 */
 int port = atoi(argv[1]);

 /*
 * 编译期选择网络模型。
 * 三个分支都把同一个 kvs_protocol 作为 handler 传入。
 */
#if (NETWORK_SELECT == NETWORK_REACTOR)
 reactor_start(port, kvs_protocol);
#elif (NETWORK_SELECT == NETWORK_NTYCO)
 ntyco_start(port, kvs_protocol);
#elif (NETWORK_SELECT == NETWORK_PROACTOR)
 proactor_start(port, kvs_protocol);
#endif
}

这里最需要记住的不是条件编译本身，而是下面三个调用具有完全相同的含义：

reactor_start(port, kvs_protocol);
ntyco_start(port, kvs_protocol);
proactor_start(port, kvs_protocol);

可以统一读作：

在指定端口启动某个网络后端；以后收到消息时，请调用 kvs_protocol()。

3. Reactor 的连接结构：`server.h`

Reactor 是事件驱动的。一次读事件和下一次写事件不是在同一个函数中连续完成，因此需要 struct conn 保存跨事件存在的连接信息。

#ifndef SERVER_H
#define SERVER_H

/* 每个连接的读、写缓冲区都是 1024 字节 */
#define BUFFER_LENGTH 1024

/* 当前 Reactor 上层启用 KVSTORE 协议 */
#define ENABLE_HTTP 0
#define ENABLE_WEBSOCKET 0
#define ENABLE_KVSTORE 1

/* epoll 事件回调：传入发生事件的 fd */
typedef int (*RCALLBACK)(int fd);

struct conn {
 int fd; // 当前连接的 socket fd

 char rbuffer[BUFFER_LENGTH]; // recv 接收到的请求
 int rlength; // 请求的实际长度

 char wbuffer[BUFFER_LENGTH]; // KV 协议生成的响应
 int wlength; // 响应的实际长度

 RCALLBACK send_callback; // EPOLLOUT 时调用 send_cb

 union {
 RCALLBACK recv_callback; // 客户端 fd 可读时调用 recv_cb
 RCALLBACK accept_callback; // 监听 fd 可读时调用 accept_cb
 } r_action;

 int status; // 连接/协议状态字段

#if 1 // websocket
 char *payload; // WebSocket 数据字段
 char mask[4]; // WebSocket 掩码字段
#endif
};

/* 同一套 Reactor 曾为不同上层协议保留入口 */
#if ENABLE_HTTP
int http_request(struct conn *c);
int http_response(struct conn *c);
#endif

#if ENABLE_WEBSOCKET
int ws_request(struct conn *c);
int ws_response(struct conn *c);
#endif

#if ENABLE_KVSTORE
int kvs_request(struct conn *c);
int kvs_response(struct conn *c);
#endif

#endif

struct conn 可以用一条数据流来理解：

recv(fd)
 ↓
rbuffer + rlength
 ↓ kvs_handler
wbuffer + wlength
 ↓
send(fd)

两个函数指针则决定 epoll 返回事件时执行什么：

监听 fd 的 EPOLLIN → accept_cb
连接 fd的 EPOLLIN → recv_cb
连接 fd的 EPOLLOUT → send_cb

4. Reactor 网络层：`reactor.c`

4.1 Reactor 总体流程

创建 epoll
 ↓
创建 20 个监听 socket，并注册 EPOLLIN
 ↓
epoll_wait
 ├─ 监听 fd 可读 → accept_cb
 ├─ 客户端 fd 可读 → recv_cb → kvs_protocol
 └─ 客户端 fd 可写 → send_cb

4.2 KV 回调和连接表

#define CONNECTION_SIZE 1048576 // 连接表容量
#define MAX_PORTS 20 // 连续监听 20 个端口

/* 计算两次 timeval 之间的毫秒差，用于 accept 统计 */
#define TIME_SUB_MS(tv1, tv2) \
 ((tv1.tv_sec - tv2.tv_sec) * 1000 + \
 (tv1.tv_usec - tv2.tv_usec) / 1000)

#if ENABLE_KVSTORE
/* reactor_start 会把 kvs_protocol 保存到这里 */
static msg_handler kvs_handler;

int kvs_request(struct conn *c) {
 /*
 * 将连接的接收缓冲区交给 KV 层；
 * KV 层把响应写入同一连接的发送缓冲区；
 * 返回值记录到 wlength。
 */
 c->wlength = kvs_handler(
 c->rbuffer,
 c->rlength,
 c->wbuffer
 );
}

int kvs_response(struct conn *c) {
 /* 当前 KV 响应不再进行二次处理 */
}
#endif

int epfd = 0; // epoll 实例 fd
struct timeval begin; // accept 统计起点
struct conn conn_list[CONNECTION_SIZE]; // 用 fd 直接索引连接

4.3 添加和切换 epoll 事件

int set_event(int fd, int event, int flag) {
 struct epoll_event ev;
 ev.events = event; // EPOLLIN 或 EPOLLOUT
 ev.data.fd = fd; // epoll 返回事件时带回这个 fd

 if (flag) {
 /* 新 fd 第一次进入 epoll */
 epoll_ctl(epfd, EPOLL_CTL_ADD, fd, &ev);
 } else {
 /* 已登记 fd 在读、写关注之间切换 */
 epoll_ctl(epfd, EPOLL_CTL_MOD, fd, &ev);
 }
}

这份 Reactor 的主要节奏，就是不断切换同一个客户端的事件：

刚建立连接 → EPOLLIN
收到并处理请求 → EPOLLOUT
发送完响应 → EPOLLIN

4.4 初始化一个客户端连接

int event_register(int fd, int event) {
 if (fd < 0) return -1;

 /* fd 同时也是 conn_list 的下标 */
 conn_list[fd].fd = fd;

 /* 客户端可读和可写时对应的处理函数 */
 conn_list[fd].r_action.recv_callback = recv_cb;
 conn_list[fd].send_callback = send_cb;

 /* 初始化这个连接的输入区域 */
 memset(conn_list[fd].rbuffer, 0, BUFFER_LENGTH);
 conn_list[fd].rlength = 0;

 /* 初始化这个连接的输出区域 */
 memset(conn_list[fd].wbuffer, 0, BUFFER_LENGTH);
 conn_list[fd].wlength = 0;

 /* 新连接加入 epoll，调用处传入的是 EPOLLIN */
 set_event(fd, event, 1);
}

4.5 创建监听 socket

int r_init_server(unsigned short port) {
 /* 创建 IPv4 TCP socket */
 int sockfd = socket(AF_INET, SOCK_STREAM, 0);

 struct sockaddr_in servaddr;
 servaddr.sin_family = AF_INET;
 servaddr.sin_addr.s_addr = htonl(INADDR_ANY); // 0.0.0.0
 servaddr.sin_port = htons(port); // 监听端口

 /* 把 socket 绑定到本机端口 */
 if (bind(sockfd,
 (struct sockaddr *)&servaddr,
 sizeof(struct sockaddr)) == -1) {
 printf("bind failed: %s\n", strerror(errno));
 }

 /* 将 socket 变为监听 socket */
 listen(sockfd, 10);

 return sockfd;
}

4.6 接受客户端

int accept_cb(int fd) {
 struct sockaddr_in clientaddr;
 socklen_t len = sizeof(clientaddr);

 /*
 * fd 是监听 socket；
 * clientfd 是新建立的客户端连接。
 */
 int clientfd = accept(
 fd,
 (struct sockaddr *)&clientaddr,
 &len
 );

 printf("accept finshed: %d,fd:%d\n", clientfd, fd);

 if (clientfd < 0) {
 printf("accept errno: %d --> %s\n",
 errno, strerror(errno));
 return -1;
 }

 /* 新客户端从等待读事件开始 */
 event_register(clientfd, EPOLLIN);

 /* 每当 fd 到达 1000 的整数倍，打印一次时间间隔 */
 if ((clientfd % 1000) == 0) {
 struct timeval current;
 gettimeofday(&current, NULL);

 int time_used = TIME_SUB_MS(current, begin);
 memcpy(&begin, &current, sizeof(struct timeval));

 printf("accept finshed: %d, time_used: %d\n",
 clientfd, time_used);
 }

 return 0;
}

4.7 接收请求并进入 KV 协议

int recv_cb(int fd) {
 /* 本次接收前清空该连接的读缓冲区 */
 memset(conn_list[fd].rbuffer, 0, BUFFER_LENGTH);

 /* 从客户端接收数据 */
 int count = recv(
 fd,
 conn_list[fd].rbuffer,
 BUFFER_LENGTH,
 0
 );

 if (count == 0) {
 /* recv 返回 0：客户端断开 */
 printf("client disconnect: %d\n", fd);
 close(fd);
 epoll_ctl(epfd, EPOLL_CTL_DEL, fd, NULL);
 return 0;
 } else if (count < 0) {
 /* recv 返回负数：打印错误并结束连接 */
 printf("count: %d, errno: %d, %s\n",
 count, errno, strerror(errno));
 close(fd);
 epoll_ctl(epfd, EPOLL_CTL_DEL, fd, NULL);
 return 0;
 }

 /* 保存这次实际收到的请求长度 */
 conn_list[fd].rlength = count;

#if 0
 /* echo 分支：直接把读缓冲复制到写缓冲 */
 conn_list[fd].wlength = conn_list[fd].rlength;
 memcpy(conn_list[fd].wbuffer,
 conn_list[fd].rbuffer,
 conn_list[fd].wlength);
#elif ENABLE_HTTP
 http_request(&conn_list[fd]);
#elif ENABLE_WEBSOCKET
 ws_request(&conn_list[fd]);
#elif ENABLE_KVSTORE
 /* 当前启用的分支：通过 handler 生成 KV 响应 */
 kvs_request(&conn_list[fd]);
#endif

 /* 请求处理完成，下一阶段等待发送 */
 set_event(fd, EPOLLOUT, 0);
 return count;
}

这里完成了项目中最重要的一次跨层调用：

recv_cb
 → kvs_request(&conn_list[fd])
 → kvs_handler(rbuffer, rlength, wbuffer)
 → kvs_protocol

4.8 发送响应

int send_cb(int fd) {
#if ENABLE_HTTP
 http_response(&conn_list[fd]);
#elif ENABLE_WEBSOCKET
 ws_response(&conn_list[fd]);
#elif ENABLE_KVSTORE
 /* KV 分支当前不对 wbuffer 做额外处理 */
 kvs_response(&conn_list[fd]);
#endif

 int count = 0;

 /* wlength 非零时，把 KV 响应发给客户端 */
 if (conn_list[fd].wlength != 0) {
 count = send(
 fd,
 conn_list[fd].wbuffer,
 conn_list[fd].wlength,
 0
 );
 }

 /* 响应阶段结束，再次等待客户端请求 */
 set_event(fd, EPOLLIN, 0);
 return count;
}

4.9 启动 Reactor 主循环

int reactor_start(unsigned short port, msg_handler handler) {
 printf("reactor_entry %d\n", port);

 /* 保存由 main 传入的 kvs_protocol */
 kvs_handler = handler;

 /* 创建 epoll 实例 */
 epfd = epoll_create(1);

 /* 从 port 开始连续建立 20 个监听端口 */
 for (int i = 0; i < MAX_PORTS; i++) {
 int sockfd = r_init_server(port + i);

 /* 监听 fd 可读时执行 accept_cb */
 conn_list[sockfd].fd = sockfd;
 conn_list[sockfd].r_action.recv_callback = accept_cb;

 /* 将监听 fd 加入 epoll */
 set_event(sockfd, EPOLLIN, 1);
 }

 /* accept 性能统计的起始时间 */
 gettimeofday(&begin, NULL);

 while (1) {
 struct epoll_event events[1024] = {0};

 /* 阻塞等待，最多取得 1024 个就绪事件 */
 int nready = epoll_wait(epfd, events, 1024, -1);

 for (int i = 0; i < nready; i++) {
 int connfd = events[i].data.fd;

 /*
 * 监听 fd：read callback 是 accept_cb；
 * 客户端 fd：read callback 是 recv_cb。
 */
 if (events[i].events & EPOLLIN) {
 conn_list[connfd]
 .r_action.recv_callback(connfd);
 }

 /* 客户端可写时调用 send_cb */
 if (events[i].events & EPOLLOUT) {
 conn_list[connfd]
 .send_callback(connfd);
 }
 }
 }
}

把整份 Reactor 压缩成一句话：

epoll 主循环根据 fd 和事件找到回调；读回调接收请求并调用 KV handler，写回调发送 handler 生成的响应。

5. io_uring Proactor 网络层：`proactor.c`

5.1 Proactor 总体流程

准备 ACCEPT 操作
 ↓ submit
等待完成队列 CQ
 ↓
ACCEPT 完成 → 得到 connfd → 准备 RECV
 ↓
READ 完成 → 调 kvs_protocol → 准备 SEND
 ↓
WRITE 完成 → 再次准备 RECV

Reactor 是“事件就绪以后调用 I/O”，这份 io_uring 代码是“先提交具体 I/O，再处理完成结果”。

5.2 操作类型与操作标记

/* 用于区分 CQE 对应哪一种操作 */
#define EVENT_ACCEPT 0
#define EVENT_READ 1
#define EVENT_WRITE 2

struct conn_info {
 int fd; // 操作所属的 socket
 int event; // ACCEPT / READ / WRITE
};

#define ENTRIES_LENGTH 1024 // io_uring 队列项参数
#define BUFFER_LENGTH 1024 // 网络缓冲区长度

/* proactor_start 保存 main 传入的 kvs_protocol */
static msg_handler kvs_handler;

每个 SQE 都通过 user_data 带上 conn_info。CQE 返回以后，程序就知道完成的是谁的什么操作。

5.3 准备 send

int set_event_send(struct io_uring *ring,
 int sockfd,
 void *buf,
 size_t len,
 int flags) {
 /* 从提交队列取得一个 SQE */
 struct io_uring_sqe *sqe = io_uring_get_sqe(ring);

 /* 标记这是 sockfd 的写操作 */
 struct conn_info info = {
 .fd = sockfd,
 .event = EVENT_WRITE,
 };

 /* 将 SQE 填写为 send 请求 */
 io_uring_prep_send(sqe, sockfd, buf, len, flags);

 /* 操作完成时，通过 user_data 找回 fd 和事件类型 */
 memcpy(&sqe->user_data, &info, sizeof(struct conn_info));
}

5.4 准备 recv

int set_event_recv(struct io_uring *ring,
 int sockfd,
 void *buf,
 size_t len,
 int flags) {
 struct io_uring_sqe *sqe = io_uring_get_sqe(ring);

 /* 标记这是 sockfd 的读操作 */
 struct conn_info info = {
 .fd = sockfd,
 .event = EVENT_READ,
 };

 /* 将 SQE 填写为 recv 请求 */
 io_uring_prep_recv(sqe, sockfd, buf, len, flags);

 memcpy(&sqe->user_data, &info, sizeof(struct conn_info));
}

5.5 准备 accept

int set_event_accept(struct io_uring *ring,
 int sockfd,
 struct sockaddr *addr,
 socklen_t *addrlen,
 int flags) {
 struct io_uring_sqe *sqe = io_uring_get_sqe(ring);

 /* 标记这是监听 sockfd 的 accept 操作 */
 struct conn_info info = {
 .fd = sockfd,
 .event = EVENT_ACCEPT,
 };

 /* 将 SQE 填写为 accept 请求 */
 io_uring_prep_accept(sqe, sockfd, addr, addrlen, flags);

 memcpy(&sqe->user_data, &info, sizeof(struct conn_info));
}

三个函数的结构完全一致，只有 prep 函数和 event 类型不同：

准备函数	liburing prep	事件标记
`set_event_accept`	`io_uring_prep_accept`	`EVENT_ACCEPT`
`set_event_recv`	`io_uring_prep_recv`	`EVENT_READ`
`set_event_send`	`io_uring_prep_send`	`EVENT_WRITE`

5.6 创建监听 socket

int p_init_server(unsigned short port) {
 /* 创建 IPv4 TCP socket */
 int sockfd = socket(AF_INET, SOCK_STREAM, 0);

 struct sockaddr_in servaddr;
 servaddr.sin_family = AF_INET;
 servaddr.sin_addr.s_addr = htonl(INADDR_ANY);
 servaddr.sin_port = htons(port);

 /* 绑定端口 */
 if (bind(sockfd,
 (struct sockaddr *)&servaddr,
 sizeof(struct sockaddr)) == -1) {
 printf("bind failed: %s\n", strerror(errno));
 }

 /* 开始监听 */
 listen(sockfd, 10);
 return sockfd;
}

5.7 初始化 io_uring 并准备第一个 accept

int proactor_start(unsigned short port, msg_handler handler) {
 /* 创建监听 socket */
 int sockfd = p_init_server(port);

 /* 保存 kvs_protocol */
 kvs_handler = handler;

 /* 初始化 io_uring 参数 */
 struct io_uring_params params;
 memset(&params, 0, sizeof(params));

 /* 创建提交队列和完成队列 */
 struct io_uring ring;
 io_uring_queue_init_params(
 ENTRIES_LENGTH,
 &ring,
 &params
 );

 /* accept 完成后，内核会填写客户端地址 */
 struct sockaddr_in clientaddr;
 socklen_t len = sizeof(clientaddr);

 /* 在进入循环之前，先准备第一个 accept SQE */
 set_event_accept(
 &ring,
 sockfd,
 (struct sockaddr *)&clientaddr,
 &len,
 0
 );

 /* READ 使用 buffer，KV 输出和 WRITE 使用 response */
 char buffer[BUFFER_LENGTH] = {0};
 char response[BUFFER_LENGTH] = {0};

5.8 提交和取得完成事件

 while (1) {
 /* 把当前已经准备好的 SQE 提交给 io_uring */
 io_uring_submit(&ring);

 /* 至少等待一个操作完成 */
 struct io_uring_cqe *cqe;
 io_uring_wait_cqe(&ring, &cqe);

 /* 一次批量取出最多 128 个完成项 */
 struct io_uring_cqe *cqes[128];
 int nready = io_uring_peek_batch_cqe(
 &ring,
 cqes,
 128
 );

 for (int i = 0; i < nready; i++) {
 struct io_uring_cqe *entry = cqes[i];

 /* 从 user_data 还原这个操作的 fd 和类型 */
 struct conn_info result;
 memcpy(&result,
 &entry->user_data,
 sizeof(struct conn_info));

这里的两个信息来源要分清：

result.fd / result.event
 提交 SQE 时由应用保存
 用来识别“谁的什么操作”

entry->res
 操作完成时由内核返回
 用来表示 accept 的新 fd、recv 长度或 send 结果

5.9 分发 ACCEPT、READ 和 WRITE 完成事件

 if (result.event == EVENT_ACCEPT) {
 /*
 * 当前 accept 已完成；
 * 先准备下一个 accept，保持继续接收新连接。
 */
 set_event_accept(
 &ring,
 sockfd,
 (struct sockaddr *)&clientaddr,
 &len,
 0
 );

 /* accept CQE 的 res 是新客户端 fd */
 int connfd = entry->res;

 /* 为新客户端准备第一次 recv */
 set_event_recv(
 &ring,
 connfd,
 buffer,
 BUFFER_LENGTH,
 0
 );

 } else if (result.event == EVENT_READ) {
 /* recv CQE 的 res 是本次收到的字节数 */
 int ret = entry->res;

 if (ret == 0) {
 /* 客户端关闭连接 */
 close(result.fd);
 } else if (ret > 0) {
 /*
 * buffer + ret 构成请求；
 * response 接收 KV 协议输出；
 * 返回值重新赋给 ret，作为响应长度。
 */
 ret = kvs_handler(buffer, ret, response);

 /* 准备把 KV 响应发送给原客户端 */
 set_event_send(
 &ring,
 result.fd,
 response,
 ret,
 0
 );
 }

 } else if (result.event == EVENT_WRITE) {
 /* send CQE 的 res 是写操作完成结果 */
 int ret = entry->res;

 /* 本轮响应结束，再次等待该客户端请求 */
 set_event_recv(
 &ring,
 result.fd,
 buffer,
 BUFFER_LENGTH,
 0
 );
 }
 }

 /* 告诉 ring：这一批 CQE 已经处理完 */
 io_uring_cq_advance(&ring, nready);
 }
}

把整份 Proactor 压缩成一句话：

每处理一个完成事件，就准备这个连接的下一项操作；READ 完成与 WRITE 准备之间插入一次 KV handler 调用。

6. ntyco 协程网络层：`ntyco.c`

6.1 ntyco 在项目中的结构

ntyco_start
 ↓ 创建
server 协程：socket → bind → listen → accept
 ↓ 每个客户端创建
server_reader 协程：recv → kvs_protocol → send

这里不展开 nty_coroutine_create 和 nty_schedule_run 的内部实现，只观察项目怎样调用框架。

6.2 客户端处理协程

/* ntyco_start 保存 main 传入的 kvs_protocol */
static msg_handler kvs_handler;

void server_reader(void *arg) {
 /* server 创建协程时传入的是 cli_fd 地址 */
 int fd = *(int *)arg;
 int ret = 0;

 while (1) {
 /* 每轮准备一个新的接收缓冲区 */
 char buf[1024] = {0};

 /* 接收这个客户端的请求 */
 ret = recv(fd, buf, 1024, 0);

 if (ret > 0) {
 /* 为本轮响应准备缓冲区 */
 char response[1024] = {0};

 /*
 * buf + ret 是请求；
 * response 是 KV 输出；
 * slength 是响应长度。
 */
 int slength = kvs_handler(buf, ret, response);

 /* 将 KV 响应发送给当前客户端 */
 ret = send(fd, response, slength, 0);

 if (ret == -1) {
 close(fd);
 break;
 }
 } else if (ret == 0) {
 /* 客户端正常关闭连接 */
 close(fd);
 break;
 }
 }
}

与 Reactor、Proactor 相比，协程版本把同一个客户端的处理过程写在一个顺序循环里：

recv(...);
kvs_handler(...);
send(...);

6.3 监听协程

void server(void *arg) {
 /* 还原 ntyco_start 传入的端口 */
 unsigned short port = *(unsigned short *)arg;

 /* 创建 IPv4 TCP 监听 socket */
 int fd = socket(AF_INET, SOCK_STREAM, 0);
 if (fd < 0) return;

 /* 填写本地监听地址 */
 struct sockaddr_in local, remote;
 local.sin_family = AF_INET;
 local.sin_port = htons(port);
 local.sin_addr.s_addr = INADDR_ANY;

 /* 绑定并监听 */
 bind(fd,
 (struct sockaddr *)&local,
 sizeof(struct sockaddr_in));
 listen(fd, 20);

 printf("listen port : %d\n", port);

 while (1) {
 socklen_t len = sizeof(struct sockaddr_in);

 /* 接受一个客户端连接 */
 int cli_fd = accept(
 fd,
 (struct sockaddr *)&remote,
 &len
 );

 /*
 * 每个客户端创建一个 server_reader 协程；
 * 该协程负责此后的 recv、KV 处理和 send。
 */
 nty_coroutine *read_co;
 nty_coroutine_create(
 &read_co,
 server_reader,
 &cli_fd
 );
 }
}

6.4 ntyco 网络层入口

int ntyco_start(unsigned short port, msg_handler handler) {
 /* 保存 kvs_protocol */
 kvs_handler = handler;

 /* 创建负责监听和 accept 的 server 协程 */
 nty_coroutine *co = NULL;
 nty_coroutine_create(&co, server, &port);

 /* 启动 ntyco 调度器 */
 nty_schedule_run();
}

把 ntyco 版本压缩成一句话：

server 协程负责产生连接，每个连接再由一个 reader 协程按顺序完成接收、协议处理和发送。

7. 三种网络层放在一起回顾

7.1 同一阶段的代码对应关系

阶段	Reactor	io_uring Proactor	ntyco
保存 KV 函数	`kvs_handler = handler`	`kvs_handler = handler`	`kvs_handler = handler`
等待连接	监听 fd 的 `EPOLLIN`	提交 `ACCEPT` SQE	`server` 协程调用 `accept`
获得连接	`accept_cb()`	`EVENT_ACCEPT` CQE	`accept()` 返回
等待请求	客户端 fd 的 `EPOLLIN`	提交 `RECV` SQE	reader 协程调用 `recv`
KV 接入点	`kvs_request()`	`EVENT_READ` 分支	`server_reader()`
发送响应	`send_cb()`	提交 `SEND` SQE	reader 协程调用 `send`
继续循环	改回 `EPOLLIN`	WRITE 完成后再提交 RECV	while 回到 recv

7.2 一次请求的三条完整路径

Reactor

epoll_wait
 → EPOLLIN
 → recv_cb
 → conn.rbuffer / conn.rlength
 → kvs_request
 → kvs_protocol
 → conn.wbuffer / conn.wlength
 → EPOLLOUT
 → send_cb
 → EPOLLIN

Proactor

提交 RECV
 → READ CQE
 → buffer / entry->res
 → kvs_protocol
 → response / 响应长度
 → 提交 SEND
 → WRITE CQE
 → 再提交 RECV

ntyco

server_reader 协程
 → recv
 → buf / ret
 → kvs_protocol
 → response / slength
 → send
 → 下一轮 recv

7.3 两种回调不要混淆

/* Reactor 内部的网络事件回调 */
typedef int (*RCALLBACK)(int fd);

/* 三种网络层共同使用的 KV 协议回调 */
typedef int (*msg_handler)(char *msg,
 int length,
 char *response);

它们的层次是：

Reactor 中：
epoll → RCALLBACK → recv_cb → msg_handler → kvs_protocol

Proactor 中：
CQE → EVENT_READ 分支 → msg_handler → kvs_protocol

ntyco 中：
server_reader → msg_handler → kvs_protocol

8. 最后的整体记忆

重新回顾这个项目时，只需要先恢复四个关键词：

NETWORK_SELECT
 决定使用 Reactor、Proactor 还是 ntyco

msg_handler
 把网络层与 KV 协议层连接起来

kvs_protocol
 接收请求、生成响应，当前实现为 echo

网络事件循环
 三种模型分别用 epoll、io_uring、协程完成连接和收发

整个程序的共同主干是：

/* main 把协议函数交给网络层 */
network_start(port, kvs_protocol);

/* 网络层保存函数地址 */
kvs_handler = handler;

/* 网络层收到请求后调用它 */
response_len = kvs_handler(
 request,
 request_len,
 response
);

/* 网络层按返回长度发送响应 */
send(clientfd, response, response_len, 0);

这四步就是六份代码共同围绕的核心。三种网络模型改变的是“请求怎样到达这四步、响应怎样离开这四步”，而 KV 协议入口保持一致。

协程运行时：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 决定怎样切过去。

协程设计原理：从异步回调到 ucontext 调度

Mon, 10 Aug 2026 00:00:00 +0800

本篇承接已有的网络 I/O、epoll 与 Reactor 笔记。这份笔记重点理解：为什么需要协程、协程怎样把异步 I/O 写成同步流程、上下文切换的三种实现方式，以及 yield、resume 和调度器之间的关系。

一、这份笔记要解决的问题

以开源协程库 ntyco 为参照，尝试逐步理解并实现一套用户态协程框架。

完整学习路线包括：

1. 为什么需要协程
2. 协程有哪些原语操作
3. 如何定义 struct coroutine
4. 如何定义 struct scheduler
5. 调度器采用什么策略
6. 如何兼容或封装 POSIX API
7. 协程从创建到退出的执行流程
8. 协程如何扩展到多核
9. 如何测试协程性能

当前真正落到代码上的内容主要是：

异步回调为什么难写
 ↓
协程如何保留同步代码结构
 ↓
上下文切换需要保存什么
 ↓
setjmp/longjmp
 ↓
ucontext
 ↓
yield / resume
 ↓
最简单的轮询调度器

后续的 struct coroutine、struct scheduler、I/O 调度、多核模式和性能测试，是建立在这些基础之上的下一阶段。

二、协程要解决什么问题

2.1 同步请求

同步代码通常按顺序执行：

func(){
send（）；
recv();
}

执行过程：

send()发起请求
 ↓
recv()等待结果
 ↓
结果返回以后继续执行

优点是代码符合人的思考顺序：

发请求 → 等结果 → 处理结果

缺点是等待 I/O 时，当前执行单元不能继续做其他工作。

2.2 异步回调

异步写法可以表示为：

callback(){
 recv();
 send(fd,cb);
 }
 func{
 send(fd,callback)
 }

执行过程：

func()发起请求
 ↓
立即返回，不阻塞当前流程
 ↓
fd就绪
 ↓
事件系统调用callback()
 ↓
callback()继续处理结果

异步的关键不是函数名字叫 async，而是：

发起操作和处理结果不在同一次连续调用栈中，中间通过事件和回调重新进入业务逻辑。

2.3 异步不等于并行

异步表示等待期间可以处理其他任务；并行表示多个任务在同一时刻由不同 CPU 核执行。

异步 → 关注等待关系
并行 → 关注是否同时执行

单线程 epoll 也可以实现异步，但它并没有同时使用多个 CPU 核。

2.4 协程的目标

回调的性能模型很好，但业务流程一复杂，就会出现多层嵌套：

请求A完成
 → 回调中发起请求B
 → B的回调中发起请求C
 → C的回调继续业务

协程希望实现：

底层：仍然使用异步事件和非阻塞I/O
上层：代码看起来像同步顺序执行

即：

底层异步，上层同步写法。

三、线程池异步与单线程同步的对比

线程池任务示例：

client_t *rClient = (client_t*)malloc(sizeof(client_t));
					memset(rClient, 0, sizeof(client_t));				
					rClient->fd = clientfd;
					
					job_t *job = malloc(sizeof(job_t));
					job->job_function = client_job;
					job->user_data = rClient;
					workqueue_add_job(&workqueue, job);

这里把 clientfd 封装进任务：

rClient->fd = clientfd
 ↓
job->job_function = client_job
 ↓
job->user_data = rClient
 ↓
workqueue_add_job()
 ↓
工作线程取出任务并执行

两种结构如下。

3.1 同一个线程检测和处理 I/O

while(1){
int nready =epll_wait();
for(int i=0;i<nready;i++){
recv(event[i].data.fd,buffer)
send(event[i]data.fd,buffer)
}
}
}
//单线程

流程：

epoll_wait()
 ↓
遍历就绪fd
 ↓
当前线程执行recv/send
 ↓
处理完成后才能继续下一个事件

3.2 epoll 线程只分发任务

void *task_callback(void *arg){
	recv(event[i].data.fd,buffer)
send(event[i]data.fd,buffer)
}
while(1){
int nready =epll_wait();
for(int i=0;i<nready;i++){
task.fd=event[i].fd
task.callback=task_callback
push_task_to_threadpool(&task);
}//多线程

流程：

epoll_wait()检测就绪
 ↓
把fd包装成task
 ↓
推入线程池
 ↓
工作线程执行recv/send

一次示例测试得到：

线程池方式：每1000连接约1500ms
直接处理：每1000连接约7300ms

这个结果只能说明当前代码、机器和负载下，任务并行处理改善了吞吐。它不能直接推导出“所有异步程序一定比同步程序快六倍”。

性能差异还可能来自：

任务中是否有阻塞操作
CPU核心数量
连接和请求模型
锁与队列开销
日志输出
测试方法
数据大小

协程与线程池也不是同一种实现：

线程池 → 内核线程并行执行任务
协程 → 通常在线程内由用户态调度器协作切换

四、为什么互联网业务需要并发等待

一个网页可能需要同时请求多个动态接口：

用户信息
文章列表
消息数量
推荐内容
广告数据
权限信息

如果完全串行：

请求1完成
 ↓
请求2完成
 ↓
请求3完成

总等待时间会累积。

如果这些请求相互独立，可以在等待某个请求时推进其他请求：

发起请求1 ─┐
发起请求2 ─┼→ 分别等待 → 谁先完成先处理谁
发起请求3 ─┘

同样的模型也会出现在：

DNS查询
HTTP请求
数据库查询
Redis请求
Kafka或MongoDB访问
文件I/O
多个客户端连接

如果请求之间存在依赖：

A的结果决定B的参数
B的结果决定C的参数

业务顺序仍然必须是 A → B → C。协程不能消除真实依赖，但可以在 A 等待期间调度其他不相关协程。

五、从回调流程演化到协程流程

5.1 回调写法

三个请求流程可以写成：

请求流程1
callback(){
 recv();
 send(fd,cb);
 }
 func{
 send_http(fd,callback)
switch(1,2)
 }

请求流程2
callback(){
 recv();
 send(fd,cb);
 }
 func{
 switch(2,3)
 send(fd,callback)
 }

请求流程3
callback(){
 recv();
 send(fd,cb);
 }
 func{
 send(fd,callback)
 switch(3,1)
 }

业务被拆散到多个 callback 中，切换关系也混在业务代码里。

5.2 协程期望的写法

希望得到的目标形式：

请求流程1

 func{
 setjmp();
asyn_send(fd,callback)

asyn_recv(fd,buffer)
 }

其他请求也保持相同的顺序结构：

请求流程2

 func{
asyn_send(fd,callback)

asyn_recv(fd,buffer)
 }

请求流程3

 func{
asyn_send(fd,callback)

asyn_recv(fd,buffer)
 }

表面看起来仍然是：

发送
 ↓
接收
 ↓
处理

但 asyn_recv() 发现 fd 尚未就绪时，不阻塞整个线程，而是让出当前协程：

async_xxx(){
if(1==poll(fd,0)){
switch();
}
}

它表达的思想是：

I/O已经就绪
 → 当前协程继续执行

I/O尚未就绪
 → 保存当前协程上下文
 → yield到调度器
 → 调度其他协程
 → fd就绪后resume回来

所以协程不是把阻塞 I/O 变快，而是在等待发生时切走。

六、协程必须具备哪些原语

最基础的协程原语可以概括为：

create → 创建协程
resume → 从调度器进入协程
yield → 协程主动让出执行权
exit → 协程执行结束
switch → 保存一个上下文并恢复另一个上下文

与 I/O 调度结合后还需要：

wait_io(fd, event) → 当前协程等待某个fd事件
wakeup(coroutine) → fd就绪后把协程变为可运行
schedule() → 选择下一个可运行协程

三者之间的关系：

resume和yield → 面向协程业务语义
switch → 底层上下文切换动作
schedule → 决定下一次resume谁

七、上下文到底是什么

协程执行到一半切走，之后还要从原位置继续，因此必须保存执行现场。

上下文通常包括：

程序计数器/指令位置
栈指针
通用寄存器
部分调用约定要求保存的寄存器
协程自己的栈
协程状态

如果只记住“执行到了哪一行”，但没有保存栈和寄存器，函数局部变量、返回地址和调用关系就无法恢复。

栈式协程通常需要：

每个协程一个独立栈
每个协程一份上下文
一个调度器上下文

I/O 模型中常见的是：

fd就绪事件
 → 找到等待这个fd的协程
 → 将协程加入ready队列

并不是 fd 本身天然等于协程；实现可以选择“一连接一协程”“一请求一协程”，也可以让一个协程等待多个事件。

八、实现上下文切换的三种方式

常见的实现方式：

1. setjmp / longjmp
2. ucontext
3. 汇编保存和恢复寄存器，例如 ntyco

8.1 setjmp / longjmp

setjmp() 保存可以恢复的执行环境，longjmp() 跳回该位置。

它适合帮助理解“保存位置并跳回来”，但它本身不自动为每个协程创建独立栈。要实现完整栈式协程，还要管理协程栈和更完整的上下文。

8.2 ucontext

ucontext 提供：

getcontext() → 获取当前上下文
makecontext() → 为上下文指定入口函数
swapcontext() → 保存当前上下文并切换到目标上下文
setcontext() → 直接恢复某个上下文

它非常适合教学，因为能够明确看到栈、入口函数和上下文切换。

ucontext 已从 POSIX.1-2008 中移除，不适合作为现代跨平台库的统一标准接口，但很多 Unix/Linux 环境仍然提供它。

8.3 汇编切换

汇编实现会按照目标架构和调用约定，直接保存、恢复必要寄存器和栈指针。

优点：

可控制保存哪些寄存器
切换路径短
适合高性能协程库

代价：

与CPU架构相关
与ABI和调用约定相关
移植成本更高
实现错误容易破坏栈

ntyco 采用汇编方式实现底层上下文切换。

九、setjmp / longjmp 原代码

setjmp / longjmp 示例代码：

#include<setjmp.h>
#include<stdio.h>
jmp_buf env;//上下文环境
void func(int arg){
 printf("func: %d\n",arg);
 longjmp(env,++arg);
}
int main(){
 
 int ret=setjmp(env);
 if(ret==0){
 func(ret);
 }else if(ret==1){
 func(ret);
 }else if(ret==2){
 func(ret);
 }else if(ret==3){
 func(ret);
 }


 return 0; 

}

9.1 jmp_buf

jmp_buf env;//上下文环境

env 用来保存 setjmp() 所需的执行环境。

9.2 第一次 setjmp()

int ret=setjmp(env);

直接调用 setjmp() 时返回 0：

ret = 0
 ↓
进入if(ret==0)
 ↓
func(0)

9.3 longjmp()

longjmp(env,++arg);

func(0) 中 arg 先变成 1，再跳回 setjmp() 保存的位置。

这一次 setjmp() 看起来像重新返回，并得到：

ret = 1

于是进入：

}else if(ret==1){
 func(ret);
}

执行过程：

setjmp首次返回0
 ↓
func(0)打印func: 0
 ↓ longjmp(...,1)
setjmp恢复后返回1
 ↓
func(1)打印func: 1
 ↓ longjmp(...,2)
setjmp恢复后返回2
 ↓
func(2)打印func: 2
 ↓ longjmp(...,3)
setjmp恢复后返回3
 ↓
func(3)打印func: 3
 ↓ longjmp(...,4)
setjmp恢复后返回4
 ↓
没有匹配分支，main结束

预期打印：

func: 0
func: 1
func: 2
func: 3

这段代码展示的是控制流跳转，还不是完整的多协程调度器。

十、ucontext 原代码：三个协程和 main 上下文

ucontext 示例代码：

#include<stdio.h>
#include<ucontext.h>

ucontext_t ctx[3];
ucontext_t main_ctx;
int count=0;
//coroutine1
void func1(void){
 while(count++<30){
 printf("1\n");
 //swapcontext(&ctx[0],&ctx[1]);
 swapcontext(&ctx[0],&main_ctx);
 printf("4\n");
 }

}
//coroutine2
void func2(void){
 while(count++<30){
 printf("2\n");
 //swapcontext(&ctx[1],&ctx[2]);
 swapcontext(&ctx[1],&main_ctx);
 printf("5\n");
 }



}
//coroutine3
void func3(void){
 while(count++<30){
 printf("3\n");
	//swapcontext(&ctx[2],&ctx[0]);
	swapcontext(&ctx[2],&main_ctx);
 printf("6\n");
 }



}
//schedule
int main(){

 char stack1[2048]={0};
 char stack2[2048]={0};
 char stack3[2048]={0}; 
 getcontext(&ctx[0]);
 ctx[0].uc_stack.ss_sp=stack1;
 ctx[0].uc_stack.ss_size=sizeof(stack1);
 ctx[0].uc_link=&main_ctx;
 makecontext(&ctx[0],func1,0);

 
 getcontext(&ctx[1]);
 ctx[1].uc_stack.ss_sp=stack2;
 ctx[1].uc_stack.ss_size=sizeof(stack2);
 ctx[1].uc_link=&main_ctx;
 makecontext(&ctx[1],func2,0); 

 getcontext(&ctx[1]);
 ctx[2].uc_stack.ss_sp=stack3;
 ctx[2].uc_stack.ss_size=sizeof(stack3);
 ctx[2].uc_link=&main_ctx;
 makecontext(&ctx[1],func3,0); 

 printf("swapcontext\n");
 swapcontext(&main_ctx,&ctx[0]);
 int i=30;
 while(count<30){
 swapcontext(&main_ctx,&ctx[count%3]);
 }
 printf("\n");






 return 0;
}

这段代码希望建立：

main_ctx → 调度器上下文
ctx[0] → func1协程
ctx[1] → func2协程
ctx[2] → func3协程

阅读第三个协程的初始化时，要按照这个对应关系理解：

ctx[2]使用stack3
ctx[2]的入口函数是func3

十一、如何创建一个 ucontext 协程

以第一个协程为例。

11.1 保存初始上下文

getcontext(&ctx[0]);

ctx[0] 获得一份可继续配置的上下文。

11.2 指定独立栈

ctx[0].uc_stack.ss_sp=stack1;
ctx[0].uc_stack.ss_size=sizeof(stack1);

含义：

stack1 → 栈起始地址
sizeof(stack1) → 栈大小
ctx[0].uc_stack → ctx[0]使用的协程栈

三个协程分别使用：

ctx[0] → stack1
ctx[1] → stack2
ctx[2] → stack3

独立栈让不同协程能够保存自己的函数调用关系和局部变量。

11.3 指定返回去向

ctx[0].uc_link=&main_ctx;

如果 func1 正常执行完并返回，运行时会转到 main_ctx。

uc_link 处理的是入口函数正常返回后的去向；func1 中主动调用 swapcontext() 则是显式 yield。

11.4 指定入口函数

makecontext(&ctx[0],func1,0);

含义：

ctx[0]第一次被resume时
 ↓
从func1开始执行
 ↓
func1没有参数

最后一个 0 表示传给 func1 的参数数量为 0。

十二、swapcontext()：保存当前上下文并恢复另一个

函数形式：

swapcontext(&from,&to);

可以理解成：

把当前执行现场保存到from
 ↓
恢复to中的执行现场
 ↓
开始运行to

12.1 main resume 第一个协程

swapcontext(&main_ctx,&ctx[0]);

含义：

保存main当前执行位置到main_ctx
 ↓
恢复ctx[0]
 ↓
第一次进入func1

func1 打印：

printf("1\n");

12.2 func1 yield 回 main

swapcontext(&ctx[0],&main_ctx);

含义：

保存func1当前执行位置到ctx[0]
 ↓
恢复main_ctx
 ↓
main从刚才swapcontext之后继续

func1 的执行位置停在：

swapcontext(&ctx[0],&main_ctx);

下一次 main 再 resume ctx[0] 时，swapcontext() 返回，继续执行：

printf("4\n");

这就是协程能够“从上次让出的位置继续”的原因。

十三、yield、resume 和 switch

三者的对应关系：

main → ctx[0] → resume协程
ctx[0] → main → yield协程
swapcontext() → 底层switch动作

13.1 resume

调度器选择一个协程
 ↓
从main_ctx切到该协程ctx
 ↓
协程开始或继续运行

13.2 yield

协程遇到I/O等待或主动让出
 ↓
保存自己的ctx
 ↓
切回main_ctx
 ↓
调度器选择其他协程

13.3 switch

switch 不关心为什么切换，只负责：

保存from
恢复to

resume 和 yield 是对 switch 在不同业务方向上的命名。

十四、当前调度器如何工作

原代码：

while(count<30){
 swapcontext(&main_ctx,&ctx[count%3]);
}

count % 3 的结果不断在 0、1、2 之间变化：

count % 3 == 0 → resume ctx[0]
count % 3 == 1 → resume ctx[1]
count % 3 == 2 → resume ctx[2]

因此它相当于一个简单轮询调度器：

main
 ↓
ctx[0]运行一段后yield
 ↓
main
 ↓
ctx[1]运行一段后yield
 ↓
main
 ↓
ctx[2]运行一段后yield
 ↓
main继续轮询

这些上下文的栈关系可以画成：

ctx3独立栈
ctx2独立栈
ctx1独立栈
main栈

这些栈并不是垂直嵌套成一条普通函数调用链，而是各自保存执行现场，由 swapcontext() 在它们之间切换。

十五、为什么当前轮询还不是 I/O 调度器

当前策略只根据：

ctx[count%3]

选择协程，它不知道：

哪个协程正在等待fd
哪个fd已经就绪
哪个协程已经结束
哪个协程可以立即运行

真正的 I/O 协程调度需要至少维护：

ready队列 → 当前可以运行的协程
waiting集合 → 等待I/O、定时器或条件的协程
epoll → 检测fd就绪
协程状态 → NEW、READY、RUNNING、WAITING、DEAD

典型过程：

协程调用异步recv
 ↓
数据尚未就绪
 ↓
把“fd → 当前协程”注册给调度器
 ↓
当前协程状态变成WAITING
 ↓
yield回调度器
 ↓
调度器resume其他READY协程
 ↓
epoll报告fd可读
 ↓
对应协程进入READY队列
 ↓
调度器再次resume它
 ↓
recv继续执行

这个过程才真正实现：

代码看起来在等待 recv，但线程没有被这个协程阻塞。

十六、协程结构体需要保存什么

进一步实现时需要定义 struct coroutine。根据前面的执行过程，它至少需要表达：

协程ID
协程状态
上下文
独立栈和栈大小
入口函数
入口参数
所属调度器
等待的fd和事件
退出结果或错误

概念结构：

struct coroutine
 ├── id
 ├── state
 ├── context
 ├── stack
 ├── function
 ├── argument
 ├── waiting_fd
 └── scheduler

这里先理解字段为什么存在，不需要脱离后续 ntyco 代码自行发明另一套结构。

十七、调度器需要保存什么

调度器负责管理所有协程并决定下一次运行谁。

概念结构：

struct scheduler
 ├── main_context
 ├── current_coroutine
 ├── ready_queue
 ├── waiting_coroutines
 ├── epoll_fd
 ├── timer
 └── all_coroutines

调度器要回答：

当前运行的是谁
哪些协程可以运行
哪些协程在等待I/O
哪些协程等待超时
fd就绪后应该唤醒谁
协程退出后怎样回收

十八、如何封装 POSIX API

一个重要设计目标，是让协程网络库尽量保持熟悉的 POSIX 调用方式。

期望上层仍然写：

connect
accept
recv
send
close

但协程封装后的行为是：

调用recv
 ↓
先尝试非阻塞recv
 ├── 已就绪：直接返回结果
 └── EAGAIN：注册EPOLLIN并yield
 ↓
 fd就绪
 ↓
 resume协程
 ↓
 再次尝试recv

这样业务代码保留同步风格，但底层仍然由 epoll 和协程调度实现异步等待。

“接口一致”不代表直接调用阻塞版本的 POSIX API，而是协程库提供行为兼容的包装层或 hook。

十九、协程怎样用于 WebServer

已有 Reactor WebServer 的逻辑：

epoll_wait
 ↓
recv_cb
 ↓
http_request
 ↓
send_cb
 ↓
http_response

协程模型可以把一个连接或一个请求组织成顺序流程：

协程开始
 ↓
等待并接收HTTP请求
 ↓
解析HTTP
 ↓
查询数据库或缓存
 ↓
构造HTTP响应
 ↓
发送响应
 ↓
等待下一次请求或退出

遇到 fd 尚未就绪时：

当前协程yield
 ↓
线程继续处理其他连接协程
 ↓
fd就绪后resume

Reactor 与协程不是互斥关系：

Reactor/epoll → 检测事件
协程调度器 → 把事件转换成协程唤醒
协程 → 承载顺序业务流程

二十、微信群聊场景应该怎样思考

思考这个场景时，不必急着寻找固定答案，先建立分析框架。

面对“微信群聊如何使用协程”时，可以依次问：

1. 一个协程对应一个连接、一个用户，还是一次消息处理？
2. 连接没有消息时，协程处于什么状态？
3. fd可读后，谁把对应协程唤醒？
4. 一条消息需要广播给多人时，哪些步骤能够并发？
5. 慢客户端发送不出去时，是否会阻塞其他用户？
6. 每个连接的发送队列放在哪里？
7. 用户断开以后，协程、fd和缓冲区如何回收？
8. 心跳和超时由谁管理？
9. 群消息顺序如何保证？
10. 多核模式下，同一个连接能否跨调度器迁移？

可以先画：

用户A连接协程
 ↓ 收到群消息
服务端业务处理
 ↓
找到群成员
 ↓
把消息加入B/C/D的发送队列
 ↓
对应连接可写时唤醒发送流程

重点不是简单回答“一个用户一个协程”，而是明确：

协程在哪里等待
什么事件唤醒
状态保存在哪里
慢连接如何隔离

二十一、协程的多核模式

单个调度器通常运行在一个线程中，同一时刻只能使用一个 CPU 核。

多核模式常见思路：

一个线程一个调度器
 ↓
每个调度器拥有自己的epoll和ready队列
 ↓
多个线程并行运行

这形成 M:N 模型：

M个协程
 ↓ 用户态调度
N个内核线程
 ↓
多个CPU核

需要处理：

连接如何分配到各调度器
协程是否允许跨线程迁移
跨线程唤醒
共享队列和锁
负载均衡
work stealing
线程局部状态

上下文通常只能在它所属的线程和栈环境中安全切换，不能随意把 setjmp/ucontext 保存的上下文拿到另一个线程恢复。

二十二、协程性能如何测试

不能只看一个“每 1000 连接耗时”。协程性能至少分成四层。

22.1 原语性能

创建一个协程的耗时
一次yield/resume的耗时
每秒可以上下文切换多少次
销毁协程的耗时

22.2 内存

每个协程结构体大小
每个协程栈大小
一万或百万协程的总内存
栈是否按需增长

22.3 I/O 服务性能

并发连接数
QPS
吞吐量
P50/P95/P99延迟
超时和错误率
CPU使用率
上下文切换次数

22.4 对比基线

应在相同业务和负载下比较：

单线程Reactor
Reactor + 线程池
Reactor + 协程
一连接一线程

只有测试业务、连接数、响应大小和日志配置相同，结果才有可比性。

二十三、核心总结

重点一：协程不是为了创造真正并行

单线程协程仍然只使用一个CPU核
协程的主要价值是等待I/O时切换任务
多核需要多个调度线程配合

重点二：协程结合了两种优点

上层：同步顺序代码，容易理解
底层：异步事件等待，不阻塞整个线程

重点三：上下文和独立栈是恢复执行的基础

上下文 → 记录执行现场
协程栈 → 保存函数调用和局部变量
switch → 保存一个上下文，恢复另一个

重点四：yield、resume 与调度器

resume → 调度器进入协程
yield → 协程返回调度器
switch → 完成底层上下文切换
scheduler → 决定下一个运行谁

重点五：真正的 I/O 协程需要 epoll

recv遇到EAGAIN
 ↓
协程注册等待EPOLLIN
 ↓
yield
 ↓
epoll报告fd可读
 ↓
协程进入ready队列
 ↓
resume
 ↓
继续recv和后续业务

最终理解：

协程不是替代 epoll，而是建立在事件驱动之上，把回调式异步流程重新组织成可顺序阅读的业务代码。

协程 on JasperSao的博客

KV 存储项目网络层：统一接入 Reactor、Proactor 与协程

1. 先恢复项目的整体画面

2. 公共入口：kvstore.h 与 kvstore.c

2.1 kvstore.h：把三种网络层统一成一种调用方式

2.2 kvstore.c：选择网络层，并把协议函数交给它

3. Reactor 的连接结构：server.h

4. Reactor 网络层：reactor.c

4.1 Reactor 总体流程

4.2 KV 回调和连接表

4.3 添加和切换 epoll 事件

4.4 初始化一个客户端连接

4.5 创建监听 socket

4.6 接受客户端

4.7 接收请求并进入 KV 协议

4.8 发送响应

4.9 启动 Reactor 主循环

5. io_uring Proactor 网络层：proactor.c

5.1 Proactor 总体流程

5.2 操作类型与操作标记

5.3 准备 send

5.4 准备 recv

5.5 准备 accept

5.6 创建监听 socket

5.7 初始化 io_uring 并准备第一个 accept

5.8 提交和取得完成事件

5.9 分发 ACCEPT、READ 和 WRITE 完成事件

6. ntyco 协程网络层：ntyco.c

6.1 ntyco 在项目中的结构

6.2 客户端处理协程

6.3 监听协程

6.4 ntyco 网络层入口

7. 三种网络层放在一起回顾

7.1 同一阶段的代码对应关系

7.2 一次请求的三条完整路径

Reactor

Proactor

ntyco

7.3 两种回调不要混淆

8. 最后的整体记忆

协程运行时：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 汇编上下文切换原代码

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

2. 公共入口：`kvstore.h` 与 `kvstore.c`

2.1 `kvstore.h`：把三种网络层统一成一种调用方式

2.2 `kvstore.c`：选择网络层，并把协议函数交给它

3. Reactor 的连接结构：`server.h`

4. Reactor 网络层：`reactor.c`

5. io_uring Proactor 网络层：`proactor.c`

6. ntyco 协程网络层：`ntyco.c`