[Back-To-Basic] - Epoll的一些事情

Epoll出现使得Linux平台上C10K迎刃而解。这里不说epoll的使用，man/google一下即可，只关注三个微小的方面:线程安全，触发机制以及客户端断开。

Epoll线程安全吗？

这个网上居然搜到的资料不多，有个简短的说法（from gejun）,

epoll_wait和epoll_ctl都是线程安全的, 前者带acquire语意, 后者带release语意, 换句话说, 如果epoll_wait后能拿到某个新fd的事件, 那么对应的epoll_ctl前发生的内存修改都可见.

其实从源码eventpoll.c的注释上一看就一目了然（主要是懒不想看源码）,详细请看注释和源码，epoll有3层锁，从上到下的顺序如下：

1. epmutex(mutex)
   eventpoll_release_file()和ep_free()需要一个全局锁
2. ep->mtx(mutex)
   event loop中从内核空间拷贝数据到用户空间需要一个允许休眠的锁
3. ep->lock(spinlock)
   从IRQ context调用的wake_up()需要操作poll callback中的对象，而在poll callback中不能休眠，所以用spinlock

边沿触发和水平触发区别和应用场景，

• 水平触发，只要fd可读/写（缓冲区不空/不满），就一直触发。
• 边沿触发，只有fd可读/写状态发送变化（翻转），才会触发。

再次引用gejun的观点：

在eventloop类型(包括各类fiber/coroutine)的程序中， 处理逻辑和epoll_wait都在一个线程， ET相比LT没有太大的差别。 反而由于LT醒的更频繁， 可能时效性更好些。 在老式的多线程RPC实现中， 消息的读取分割和epoll_wait在同一个线程中运行， 类似上面的原因， ET和LT的区别不大。但在更高并发的RPC实现中， 为了对大消息的反序列化也可以并行， 消息的读取和分割可能运行和epoll_wait不同的线程中，这时ET是必须的，否则在读完数据前，epoll_wait会不停地无谓醒来。

客户端断开

某服务端的fd与客户端的连接断开会使得该fd状态变成可读，但是在read的时候会返回0即EOF，这时可以close并且将该fd从epoll events中移除(EPOLL_CTL_DEL)。