Andy Pan
Andy Pan
> 另一个诡异的点我还没找到原因：在这一刻，Client 没有异常退出，服务也没有 panic，但是这个 Client 上的所有连接都断了(看表现是每条连接都调用了 OnClose)。 这个不是你前面说的触发了服务端的某个条件被主动关闭了吗？那这里 client 的连接也是会收到断开的通知啊！
> 简单总结一下：标题不是 gnet 的 bug，是使用过程中 `业务异常 + gnet WriteCallback 设计未考虑 write error` 一起导致的。 > > 对于 gnet，个人觉得还是有以下可优化的点： > > 1. `AsyncWrite(buf []byte, callback AsyncCallback) (err error)` 中的 `AsyncCallback` 函数，参数中可以携带真正 write...
这样的话，`gnet.Conn` 接口要新增方法，得不偿失。
> > 简单总结一下：标题不是 gnet 的 bug，是使用过程中 `业务异常 + gnet WriteCallback 设计未考虑 write error` 一起导致的。 > > 对于 gnet，个人觉得还是有以下可优化的点： > > > > 1. `AsyncWrite(buf []byte, callback AsyncCallback) (err error)` 中的...
Related issue: #328
你可以尝试设置 ants pool 的 capacity 是无限的，这样 ants 就不会限制 worker 数量，只对 goroutine 进行复用。
这里 https://pkg.go.dev/github.com/panjf2000/ants/v2#NewPoolWithFunc，size 传入 -1 即可。
> > `gnet` 是基于事件驱动的，`Read()/Peek()` 这些 APIs 只在 `Ontraffic()/OnOpen()` 这几个事件回调里才能调用，这里读取的是已经存入本地 buffer 的数据，所以是非阻塞的，而且一定能读到数据，不像标准库是直接调用系统调用 `read()` 去 socket fd 尝试读数据，如果 socket buffer 没数据则挂起当前 goroutine，所以 `gnet.Conn` 并不需要这几个 APIs。 > > 您好，我现在需要做一个文件拉取的工作，现在发现没有当服务器上把数据写完了，但是本地会丢失很多文件，问题应该是默认的缓存不够，导致数据覆盖，所以就丢失了。请问这个应该怎么处理？如果read()可以使用，那么我每发送一个文件就可以使用read()去阻塞，当接收到了客户端的消息，再继续往下走，但是现在这个不能使用了 信息太少，不是很理解你的场景，麻烦说详细点，最好能附上 demo 代码。
https://github.com/viosey/hexo-theme-material
I had to exclude Windows currently to get rid of these false positives but still, it is not the radical solution, so I'm hoping that we can locate the root...