poller没有区分提交的是读还是写请求问题 about gaio HOT 9 OPEN

不会被”不断唤醒“， 因为有EPOLLONESHOT

from gaio.

因为你readers不为空，会一直Rearm，重现步骤是：启动echo server，客户端发起连接，但是不发任何数据。

from gaio.

因为你readers不为空，会一直Rearm，重现步骤是：启动echo server，客户端发起连接，但是不发任何数据。

仔细看代码

from gaio.

这是我启动echo_server, telnet 连接上去，CPU的占用

from gaio.

这是我启动echo_server, telnet 连接上去，CPU的占用

看到了，确实有这个问题。

from gaio.

fix了

from gaio.

还有个问题，我注意到你使用了EPOLLONESHOT|EPOLLET方式添加到epoll，但是每次从fd读数据（tryRead函数）并没有保证读干净（一直读到EAGAIN）。比如客户端向服务端发送7K数据并停止，服务端内核buffer中立即收到了7K数据，这时发起一个异步读请求ReadFull 4K数据能返回，但是后面只要客户端不再发数据，因为ET模式的缘故，就再也不会唤醒读了，导致剩余3K数据读不到。

from gaio.

还有个问题，我注意到你使用了EPOLLONESHOT|EPOLLET方式添加到epoll，但是每次从fd读数据（tryRead函数）并没有保证读干净（一直读到EAGAIN）。比如客户端向服务端发送7K数据并停止，服务端内核buffer中立即收到了7K数据，这时发起一个异步读请求ReadFull 4K数据能返回，但是后面只要客户端不再发数据，因为ET模式的缘故，就再也不会唤醒读了，导致剩余3K数据读不到。

不会

from gaio.

除了EPOLLONESHOT确实没法不浪费重复触发并反向传导流控，但是EPOLLONESHOT的syscall更多也确实是浪费性能，我最初只用EPOLLLT没支持EPOLLET，后来增加了支持，但是没支持EPOLLONESHOT，最近也在琢磨可不可以折衷一点，EPOLLET不带EPOLLONESHOT，fd上带个当前state、如果已经可读则不重复派发给应用，标准库似乎就是这种但runtime还自带了调度。
通常情况下交互，EPOLLET的未读完时新数据到来导致重复事件的浪费情况很少，kcptun这种隧道性质的跟普通的业务应用相比确实是特殊场景。
如果是kcptun这种，EPOLLET即使重复派发但应用层仍然根据流控的反向传导来决定要不要读，即使重发派发了其实应该也还好，被反向流控时等待了，系统本来也就不繁忙，所以即使多触发几次事件也不会太影响吞吐
而对于普通应用每个conn其实重复触发的概率很低，所以也不太会影响吞吐

所以要不要考虑下去掉EPOLLONESHOT？去掉的话，真正跑很高量的场景下，省掉的syscall可能会让吞吐好于现在的

from gaio.