> 1. man 7 epoll 说的很清楚
> The suggested way to use epoll as an edge-triggered (EPOLLET) interface is as follows:
> a) with nonblocking file descriptors; and
> b) by waiting for an event only after read(2) or write(2) return EAGAIN.
> 你必须要读到返回 errno=EAGAIN ，如果我是水平模式，不没必要

> 2. 你这属于抬杠，在多少情况是 socket 缓冲区暴满了？要考虑大部分情况的代码分支走向
> 1 ）程序处理的慢，读不过来，堆积了
> 2 ）业务类型就是客户端不停的 send （也得看处理的快慢）
> 这都不是关键问题，多路复用同步的读取 你可以把 recv buf 搞得很大，因为它是共享的，不存在浪费内存的问题。

你好像没看懂我在说什么，我说的是你当前这个 LT 单次 event 不读完的实现，与 ET 单次读完的区别，我没说你 bug 啊也没说你一定需要读完啊，你再看下 #111

> 你这属于抬杠，在多少情况是 socket 缓冲区暴满了？要考虑大部分情况的代码分支走向

单次读完相比于你当前的 LT 单次不一定读完，也并不多浪费什么代码，也就循环里多个 if EAGAIN 的判断。而且我也没说必须这样做，只是分析你的 LT 实现与 ET 的区别，没说你这个实现就影响性能了或是怎么样，而是说 `这样未必最优`，我可不是说你这样一定不如单次读完啊。

你这么容易觉得我在抬杠，没必要。人在觉得发现新大陆、搞了大进步的时候最容易自我陶醉、也最容易听不进去跟自己不同的观点，很正常。
你可以先让自己冷静下来再看看，或许能吸收些新东西。


另外：
> 你必须要读到返回 errno=EAGAIN

并不是必须这样的，自己想做流控的话，可以自行选择读多少、什么时候继续读，比如 golang ，有数据来了 net.TCPConn 就可读，但是你应用层没有调用 net.TCPConn.Read 也没关系啊，你什么时候想读直接能读就醒了，如果当前没数据不可读、阻塞在那等 runtime event 来了唤醒就可以了

man 手册离的是那是 `The suggested way`, 因为 ET 数据没读完、没有新数据到来是不会再触发可读的、如果用户解析处理逻辑有 bug 并且不继续读和处理就可能僵尸连接了。
但请你看清楚，那 `You must do it`，所以 `必须要读到返回 errno=EAGAIN` 这说法也是不准确的。


> 另外，我回复中写的是 EAGAIN ，不是 EINTER 。

我上面说的不是你回复其他人的 EAGAIN ，而是说你源码中的这块，我上面漏贴了代码链接：
https://github.com/shaovie/niubix/blob/main/src/io_handle.cpp#L24

> 3. 是不完整，我惊讶的是给我的性能发挥空间还很大啊，如果只是性能超过 haproxy 20%,那我就没啥好惊讶的，等我完善 完善 可能这 20%就被抹平了

那可以惊讶的事情可真是太多了，你继续加油提高性能天花板吧

> 我说的读的情况多一次 syscall ，指的是 read ，不是 epoll_ctl

读的时候，ET 怎么就可能比 LT 多一次 syscall 了呢？同样一次读事件到来，同样的 read buf 。
你是不是又搞混了什么。。