io_getevents(2)遭信号中断返回部分事件时是否需消费？libaio如何处理？

根据io_getevents(2)的文档说明：

调用成功时，io_getevents()返回读取到的事件数量。若超时，返回值可能为0或小于min_nr；若被信号处理程序中断，也可能返回非零但小于min_nr的数值。

这段说明指出，当出现EINTR错误时，调用可能返回部分事件，但有个关键点不明确：调用者应当消费这些返回的部分事件，还是需要重试调用直到获取至少min_nr个预期的成功事件？

是否应当像read()调用那样处理部分事件？比如可以参考以下示例代码的逻辑：

ssize_t io_wait_for_events(io_context_t ctx, struct io_event *events, int min_nr, int max_nr) {
    ssize_t num_events = 0;
    do {
        // 尝试获取事件（若被中断可能返回少于min_nr的数量）
        num_events = io_getevents(ctx, min_nr, max_nr, events, nullptr);
        
        if (num_events >= 0) {
            // 处理成功获取到的事件
            if (num_events > 0) {
                process_events(events, num_events);  // 处理部分获取的事件
            }

            // 检查是否需要重试以获取更多事件
            if (num_events < min_nr) {
                min_nr -= num_events; // 调整还需要获取的事件数量
                events += num_events; // 移动事件指针到下一个位置
            }

        } else if (num_events == -EINTR) {
            // 若被信号中断则重试（未获取到有效事件）
            continue;

        } else {
            // 处理io_getevents的其他潜在错误
            std::cerr << "io_getevents 错误: " << strerror(-num_events) << std::endl;
            return num_events;
        }
    } while (num_events < min_nr);  // 持续尝试直到获取至少min_nr个事件
    
    return num_events;
}

另外，io_getevents(3)的手册甚至完全没有提及调用被中断的情况，使用libaio包装API时，开发者该如何处理这种场景？

核心处理原则 #

• 必须消费已返回的部分事件：io_getevents返回的非零正数代表已经成功从内核获取到对应数量的IO完成事件，这些事件是有效的，必须立即处理——否则会导致事件丢失，后续调用无法再次获取到这些已完成的事件。
• 区分EINTR与部分事件返回：
  • 当返回值为-EINTR时，说明调用未获取到任何有效事件，直接重试即可，无需调整事件指针或剩余需求数量。
  • 当返回值为正数但小于min_nr时（无论是否由中断导致），先处理已返回的事件，再调整min_nr和事件指针，继续调用直到满足最小事件数要求，或遇到其他错误。

libaio包装API的处理建议 #

虽然io_getevents(3)手册未提及中断场景，但底层依赖的系统调用io_getevents(2)存在该情况，因此使用libaio时仍需遵循系统调用的处理逻辑：

• 不要假设libaio会自动处理EINTR，必须在代码中显式检查返回值是否为-EINTR，并执行重试逻辑。
• 对于返回的部分事件，同样需要先消费再重试，避免事件丢失。

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