epoll_wait不能在协程中直接调用，必须由事件循环在独立线程或主线程中轮询并分发就绪事件；需用自定义promise_type管理fd等待队列、合并事件掩码、处理EPOLLONESHOT重注册及协程销毁清理。
epoll_wait 不能直接挂起协程，得靠事件循环调度
协程本身不感知 I/O 事件，epoll_wait 是阻塞调用，直接在协程里调用会卡住整个线程。必须把 epoll_wait 放在独立线程或主循环中轮询，再把就绪事件分发给对应协程恢复执行。
- 常见错误：在协程体内写
epoll_wait(fd, events, max_events, -1)—— 这会让当前协程所在的线程彻底阻塞，其他协程无法调度 - 正确做法是让事件循环（比如一个 dedicated thread 或主线程）持续调用
epoll_wait，拿到就绪fd后，通过coroutine_handle::resume()唤醒等待该 fd 的协程 - 需要为每个待监听的 fd 维护一个等待队列，例如
std::unordered_map<int std::vector>>></int>
用 promise_type 拦截协程挂起，绑定 fd 和事件类型
协程暂停点（比如等待读就绪）必须能关联到具体 fd 和期望事件（EPOLLIN / EPOLLOUT），这靠自定义 promise_type 实现。
- 在
await_suspend中注册 fd 到 epoll 实例，并把当前coroutine_handle存入对应 fd 的等待列表 - 注意：同一个 fd 可能被多个协程等待不同事件，需按事件掩码合并注册（比如已有
EPOLLIN，新协程要EPOLLOUT，就得用EPOLL_CTL_MOD更新events字段） - 别忘了在
await_resume里清理等待列表，否则 fd 关闭后残留 handle 会 crash
epoll_ctl 的 EPOLLONESHOT 必须配合手动重注册
不用 EPOLLONESHOT 容易重复唤醒同一协程；但用了它，每次处理完事件后必须显式调用 epoll_ctl(EPOLL_CTL_MOD) 重新启用监听，否则后续事件收不到。
- 典型坑：协程 resume 后直接返回，忘记调用
epoll_ctl，结果 fd 就“静音”了，调试时表现为连接突然不响应 - 建议在
await_resume返回前做一次重注册，参数保持原events不变 - 如果协程中途被销毁（比如超时取消），也要确保从 epoll 中移除 fd 或至少清空其等待队列，避免 dangling handle
Linux 6.8+ 的 io_uring + C++20 协程更省事，但 epoll 兼容性更好
io_uring 原生支持异步提交/完成，和协程天然契合，C++23 标准库也在推进 std::generator 和 std::task 对它的适配。但如果你的目标系统是 CentOS 7、glibc 2.17 或旧内核，io_uring 直接不可用。
立即学习“C++免费学习笔记（深入）”；
- epoll 方案在 2.6.19+ 内核全支持，编译期只依赖
<sys/epoll.h>，无运行时模块要求 - 性能上，epoll 在连接数少于万级时和 io_uring 差距不大；但 epoll 的 event loop 要自己写调度逻辑，io_uring 只需提交 sqe、等 cqe
- 目前主流协程库如 libunifex、cppcoro 都优先封装 io_uring，epoll 属于“要自己撸”的范畴
真正麻烦的不是 epoll 本身，而是把 fd 生命周期、事件合并、协程生命周期、线程安全这几件事串成一条不掉链子的流水线。稍有错位，就会出现唤醒丢失、double resume 或 use-after-free。
