Andy Pan

`AsyncXX` 函数和回调函数返回的 error 通常是系统调用的错误，系统调用报错的概率极小，可以认为这些函数返回的错误永远是 error == nil，但理论上还是有可能 err != nil，判断一下就行。 > 如果AsyncWritev返回错误，是否内部的回调函数一定不会执行，如果asyncWritev不返回错误，内部的回调函数一定执行? 没有必然关系，不能依赖这个逻辑关系。

> 当前遇到的问题是，为了减少内存分配，用pool来分配asycwritev分配的对象，然后这个异步的方法，内部cb不一定会执行，并且外部的err不为nil的时候内部的cb也可能执行，无法确定pool分配的对象的返回时机. 抱歉，之前太忙忘了回复了，事实上你可以不用纠结这种分配回收的时机问题，一开始引入 callback 就是为了这种场景，你可以直接在 callback 里回收资源。事实上，callback 理论上是永远都会执行的，否则的话，那就是很严重的 bug。

> 我认为还是接口设计的问题，err同步的的时候直接返回，异步的时候通过cb的参数返回 至于说 API 简化的问题，因为现在已经发布了 v2 版本了，API 变更这种属于 breaking changes，只能放到下一个 major 版本里考虑了。 不过至于异步 API 是否要同步返回 error 的问题，这里我还是认为需要返回，因为这个 error 它就是可能发生的同步的错误，是提交任务是否完全成功的反馈，而通过 callback 返回的 error 实际上是异步代码真正执行过程中发生的错误。这两种 error 还是解耦一下比较好。

有没有服务端的具体堆栈信息或者日志？还有，有没有尝试查看进程的 TCP 连接是否全都销毁了，或者还有残存？

这里的内存管理是指什么？能具体说一下吗？

用 `sync.Pool` 就能实现一个简单的内存池了，结合 asyncwritev 的回调函数可以方便地回收内存到 pool，自己管理这部分在我看来也不麻烦啊，还是说你还想要其他的东西？能不能用(伪)代码具体表示一下你的确切需求？

你的业务场景是不是单核心就足够了，设置多核心反而因为上下文切换而降低了性能？

你绑了多少个 CPU 到进程上？ 然后你说不设置 option.multicore 和 option.NumEventLoop 性能更好？

你能提供一下复现步骤吗？最好是有 demo 代码可以测试。

#413