标签: io_uring
与该标签相关的所有文章 "io_uring".
-
C++ 协程：语言机制、陷阱与实现边界
C++20 协程的本质是编译器把带 coawait/coyield/coreturn 的函数重写成状态机，把跨 suspend 存活的变量打包到一个堆上的 frame——这是语言级 stackless 协程，不是 Goroutine 式 stackful。标准库只给了 coroutinehandle / suspendalways / suspendnever 这几块地基，不给 Task<T>、不给 Generator（C++23 才加）、不给 executor、不给调度器。要在网络服务器里用，必须自己实现 Task<T>（严格遵守 symmetric transfer 否则链式 coawait 直接栈溢出）+ IoUringAwaiter（绑定到 reactor）。三大杀手级陷阱：协程参数必须按值传（引用参数跨 suspend 必悬挂）、finalsuspend 必须 suspend_always（否则 double-free）、热路径不能依赖 HALO，需要自定义 operator new。
-
Linux I/O(二)：io_uring 的双环模型与工程边界
iouring 的本质不是"更快的 epoll"，而是用户态和内核态共享两个 mmap 环（SQ 提交环 / CQ 完成环）+ 完成模型（submit then wait for completion），统一覆盖文件 / socket / timer / futex 的异步。相较 epoll 的 readiness 模型，它在存储 I/O（libaio 无法 buffered）和syscall 密集场景（SQPOLL 下热路径零 syscall）有质变；对已优化过的 epoll 网络栈提升只有 10–30%。工程上的真实门槛是内核版本下限 ≥ 5.15、容器 seccomp 默认屏蔽、安全 CVE 历史重、多云厂商禁用，以及一条必须铭刻的规则：CQE 的完成顺序和 SQE 的提交顺序无关，必须靠 userdata 关联。
-
asio(五)：操作系统I/O多路复用-epoll、kqueue、IOCP如何被统一
Asio 通过编译期条件选择 reactor 实现（epollreactor / kqueuereactor / winiocpiocontext），每种实现共享统一的内部接口（registerdescriptor、startop、cancelops、run、interrupt）。Linux/macOS 是 Reactor 之上模拟 Proactor，Windows 是原生 Proactor 直通 IOCP。io_uring 作为第四种后端在 Boost 1.78+ 可选启用。