io_uring_wait_cqe_nr为何未像peek_batch_cqe批量填充CQE数组

两个接口行为差异本质是定位完全不同，遵循liburing的逻辑分层设计原则，不存在功能缺陷：

• io_uring_peek_batch_cqe属于纯无阻塞的收割类接口，核心目标是尽可能降低收割CQE的开销：直接从完成队列的已就绪区域批量拷贝CQE指针到用户传入的数组，有多少拿多少，全程不触发阻塞、不进入内核态，拿完立刻返回，所以它天然会批量填充数组。
• io_uring_wait_cqe_nr属于阻塞等待类接口，它的wait_nr参数语义根本不是「要取出的CQE数量」，而是「阻塞等待的触发阈值」：如果当前完成队列里的已就绪CQE数量小于wait_nr，就会通过系统调用陷入内核阻塞，直到队列里的就绪CQE数达到阈值、被信号打断或者超时才返回。它的核心作用只是帮你省掉手动轮询队列长度的逻辑，保证返回时队列里至少有wait_nr个可用CQE，并不负责把这些CQE取出来。

为什么不在等待接口里实现批量填充？ #

liburing刻意把等待逻辑和CQE收割逻辑解耦，避免重复实现相同功能：不管你用哪种等待接口（io_uring_wait_cqe、io_uring_wait_cqe_nr、io_uring_wait_cqe_timeout），等满足唤醒条件之后，都可以统一调用io_uring_peek_batch_cqe一次性收割所有已就绪的CQE，不需要每个等待接口都单独写一套批量拷贝CQE的逻辑，代码复用率更高，也不会带来额外性能开销。

正确使用示例 #

你之前的用法存在内存风险：io_uring_wait_cqe_nr只会往cqe_ptr指向的地址写入1个CQE指针，不会操作数组后续位置，直接访问cqes[1]及以上索引会读到未初始化的野指针。
实现「等待N个事件就绪后批量收割」的标准写法如下：

#define MAX_BATCH 2000
// 唤醒阈值：队列里至少有1个就绪事件就唤醒，适配低延迟场景；高吞吐场景可以设为8/16等数值减少上下文切换
#define WAKEUP_THRESHOLD 1

struct io_uring_cqe *cqes[MAX_BATCH];
int ret;

// 第一步：阻塞等待直到满足唤醒条件
ret = io_uring_wait_cqe_nr(ring, &cqes[0], WAKEUP_THRESHOLD);
if (ret < 0) {
    // 对应错误处理，比如处理-EINTR信号打断等场景
}

// 第二步：无阻塞批量收割所有已就绪的CQE
unsigned ready_cnt = io_uring_peek_batch_cqe(ring, cqes, MAX_BATCH);
for (int i = 0; i < ready_cnt; i++) {
    // 处理单个CQE的业务逻辑
    struct io_uring_cqe *cqe = cqes[i];
    // ... 业务处理
    
    // 标记CQE已处理
    io_uring_cqe_seen(ring, cqe);
}

补充说明 #

wait_nr设置的只是最低唤醒阈值，不是精确的事件数量：当进程被唤醒时，完成队列里的已就绪CQE数量大概率会超过你设置的wait_nr值，后续接io_uring_peek_batch_cqe可以一次性把所有就绪事件全部取完，避免多次进内核的开销，这也是liburing推荐的高吞吐最佳实践。

内容的提问来源于stack exchange，提问作者QuickQuail