epoll EPOLLOUT
场景：epoll epollout,该如何处理
epoll epollout
发现以前有人在别的地方问过类似的问题，但是没人解答：
“Linux下的I/O复用epoll，我一直对这个EPOLLOUT事件有一些疑问
当我们调用epoll_wait函数返回时，我们应该可以获得一个就绪事件的列表，然后我们可以遍历这个列表，然后查看每一个就绪的文件描述符上发生的事件，然后针对不同的时间进行操作。
对于常用的EPOLLIN，EPOLLRDHUP我都理解，例如
在发生EPOLLIN的时候，如果是监听socket上，那么我们调用accept来接受新连接
如果是普通socket，那么我们调用recv来接受新数据。
可是对于EPOLLOUT事件，其表示数据可写。但是在服务器一端来说，一般时我们接受客户端的请求，然后处理请求，最后直接将处理结果调用send函数发送给客户端，我实在没有看出在这一步有任何需要在调用epoll_wait函数等待EPOLLOUT事件的必要，
或者说，我不是很了解在什么情况之下调用epoll_wait函数后会触发EPOLLOUT事件，以及当我们检测到这个事件发生的时候我们应该如何处理这个事件。
等待高人解答呀 ”
补充一下：很多通信都不是严格 ：接收---发送--接收
而是：接收--接收。。。直到有结束标志---发送---接收
所以在epollin之后，立刻mod到epollout是不正确的
另外epollin就可以监听read的socket了。然后write这个socket就可以了。完全可以不用epollout啊
------解决思路----------------------
假如这个socket的缓冲一直是满的，因为某些原因，这个socket的数据一直无法发送出去，所以它不能清空自己的缓冲。这个时候你直接send会有什么后果？只能是使得这个send阻塞了。这里epollout就有用了。它可以避免你乱来。
为什么你觉得服务器端send操作就一定可以成功？
------解决思路----------------------
这个跟“顺序”没有关系。
只是表示“可以无阻塞的执行写操作”，至于写操作为何会阻塞，原因相当多。
------解决思路----------------------
不知道有多少前人掉在TCP Socket
send(人多)send(病少)send(财富)
recv(人多病)recv(少财富)
陷阱里面啊！
http://bbs.****.net/topics/380167545
------解决思路----------------------
举两个TCP的例子
1. 有拥塞控制， 对方一直读数据， 导致接收窗口越来越小， 因此内核只能为你缓存包，当缓存耗尽， 再send就会阻塞了。
2. 网络异常， 一直没有ACK， 但是没有检测连接已经断开， 这是内核也会缓存已经发送过的数据。。。
------解决思路----------------------
epoll是开源的吧。
epoll epollout
发现以前有人在别的地方问过类似的问题，但是没人解答：
“Linux下的I/O复用epoll，我一直对这个EPOLLOUT事件有一些疑问
当我们调用epoll_wait函数返回时，我们应该可以获得一个就绪事件的列表，然后我们可以遍历这个列表，然后查看每一个就绪的文件描述符上发生的事件，然后针对不同的时间进行操作。
对于常用的EPOLLIN，EPOLLRDHUP我都理解，例如
在发生EPOLLIN的时候，如果是监听socket上，那么我们调用accept来接受新连接
如果是普通socket，那么我们调用recv来接受新数据。
可是对于EPOLLOUT事件，其表示数据可写。但是在服务器一端来说，一般时我们接受客户端的请求，然后处理请求，最后直接将处理结果调用send函数发送给客户端，我实在没有看出在这一步有任何需要在调用epoll_wait函数等待EPOLLOUT事件的必要，
或者说，我不是很了解在什么情况之下调用epoll_wait函数后会触发EPOLLOUT事件，以及当我们检测到这个事件发生的时候我们应该如何处理这个事件。
等待高人解答呀 ”
补充一下：很多通信都不是严格 ：接收---发送--接收
而是：接收--接收。。。直到有结束标志---发送---接收
所以在epollin之后，立刻mod到epollout是不正确的
另外epollin就可以监听read的socket了。然后write这个socket就可以了。完全可以不用epollout啊
------解决思路----------------------
假如这个socket的缓冲一直是满的，因为某些原因，这个socket的数据一直无法发送出去，所以它不能清空自己的缓冲。这个时候你直接send会有什么后果？只能是使得这个send阻塞了。这里epollout就有用了。它可以避免你乱来。
为什么你觉得服务器端send操作就一定可以成功？
------解决思路----------------------
这个跟“顺序”没有关系。
只是表示“可以无阻塞的执行写操作”，至于写操作为何会阻塞，原因相当多。
------解决思路----------------------
不知道有多少前人掉在TCP Socket
send(人多)send(病少)send(财富)
recv(人多病)recv(少财富)
陷阱里面啊！
http://bbs.****.net/topics/380167545
------解决思路----------------------
举两个TCP的例子
1. 有拥塞控制， 对方一直读数据， 导致接收窗口越来越小， 因此内核只能为你缓存包，当缓存耗尽， 再send就会阻塞了。
2. 网络异常， 一直没有ACK， 但是没有检测连接已经断开， 这是内核也会缓存已经发送过的数据。。。
------解决思路----------------------
epoll是开源的吧。