关于epoll的IO模型是同步异步的一次纠结过程

这是一次概念的纠结过程，对写代码没有太大意义。

过程是这样的：

首先，我的概念里往往只有同步和异步，没有太多去区别同异步IO和同异步通知两种。

另外还记得apu(2rd)中有一句“select和poll可以实现异步形式的通知”。

接着，听到了epoll是同步IO这个概念，比较意外。坚持了一下后，查到如下概念：

在unp(3rd)里的定义是：

第一是IO操作的概念：

IO操作包括：

1.等待数据准备好。

2.从内核到进程拷贝数据。

第二就是是同步IO和异步IO的区别：

同步IO导致请求进程阻塞，直到IO操作完成。

异步IO不导致请求进程阻塞。

得到的结论：

阻塞IO模型，非阻塞IO模型，IO复用模型，信号驱动IO模型都是同步IO。

epoll也是IO复用模型，应该是同步IO。

此时又意外了，再看到一个解释：

更为重要的是, epoll 因为采用 mmap的机制, 使得 内核socket buffer和 用户空间的 buffer共享, 从而省去了 socket data copy, 这也意味着, 当epoll 回调上层的 callback函数来处理 socket 数据时, 数据已经从内核层 "自动" 到了用户空间, 虽然和 用poll 一样, 用户层的代码还必须要调用 read/write, 但这个函数内部实现所触发的深度不同了.

用 poll 时, poll通知用户空间的Appliation时, 数据还在内核空间, 所以Appliation调用 read API 时, 内部会做 copy socket data from kenel space to user space.

而用 epoll 时, epoll 通知用户空间的Appliation时?, 数据已经在用户空间, 所以 Appliation调用 read API 时?, 只是读取用户空间的 buffer, 没有 kernal space和 user space的switch了.

于是想了一下：

明显没有IO操作的拷贝数据到内核空间了，stevens应该在99年就挂了，2.6内核的epoll才采用mmap机制，书籍偏旧了吧。

那么epoll是异步IO了吧。

然后再一看，你妹的，这还是不符合异步IO啊，毕竟epoll在告知OK前，是阻塞了，虽然是拷贝数据结束了。

看来好像应该修正的是IO操作定义的第二步才对，而不是那个区别。

好吧，你就暂时属于同步IO了，专心看代码，不纠结概念了。