请求几个问题 about nbio

[lesismal]

感谢关注和支持！

1. ...如果同一个epoll 里多个conn 读事件到来，那么处理的时候，后面的就只能等前面的结束了。

默认使用的 LT，LT模式下，如果本次 epoll loop 1 中派送事件给异步协程池去读，读协程池尚未读取时就可能 epoll loop 1 结束，因为尚未读取，则仍然可读、LT模式会再次触发 epoll_wait 返回，所以进入 epoll loop 2、重复去派发读事件，造成事件和实际syscall重复浪费。
不同模式压测后我的环境下 LT 性能最好，而且即使异步读，涉及协议解析之类的 cpu 消耗，实际并发度仍然受到核心数限制，单独的异步读协程池数量也不适合太大、也还是涉及排队的问题，所以默认使用的 LT。

但是 nbio 是支持 epoll mod 可配置的，也支持 ET，但是不支持 ET+ONESHOT，因为 ONESHOT 每次都要重新添加事件、性能比较差一些。
EpollMod 参数配置成 EPOLLET，用户还可以使用 g.OnRead 自行定制读取方式是同步还是异步或者其他的细节，当设置了 g.OnRead 时，g.OnData 失效。

IO协程数量也是可配置的，所以，只要用户喜欢，像runtime那样只使用一个 epoll loop + ET + 多个读协程都是可以的。

从使用的自由度来讲，用户可以定制不同的读策略从而自由选择 Reactor 或 Proactor 。

2.write 会限制包大小，直接返回错误，而不是底层分批处理掉，是出于大包攻击考虑吗？

nbio.Conn 是根据配置做 write size 限制，默认的 MaxWriteBufferSize 为0则不限制。nbio.Conn提供的是基础设施，就像 syscall write 一样，实际的写入逻辑应由用户控制。
MaxWriteBufferSize 主要是避免应用层不慎、窗口拥塞缓存的待写入数据太大等情况可能导致的OOM。除了 MaxWriteBufferSize，用户还应该合理使用 SetWriteDeadline 等、对僵尸连接、窗口拥塞已经不健康的连接进行及时关闭

3.调用底层中读写的代码都有一个 if n<0 的判断，真的会出现小于0吗？

syscall read/write 的返回值可以查看下 man 2 read/write，返回值-1时配合对应的 errno 进行处理：