someview

如果去掉test，运行是正常的

> 我这可以的么，给个完整可复现的例子 example ，或者试下最新 dev version。。`xmake update -s dev` > > ```lua > add_rules("mode.debug", "mode.release") > > set_languages("c++latest") > > target("stdmodules_cpp_only") > set_kind("binary") > add_files("src/*.cpp") > set_policy("build.c++.modules", true) > >...

升级一下版本就没这个问题了，已经解决，module里也可以有test了

> 尽管理论上，随意切换 toolchain 肯定能实现，但是要考虑到现在，我单人的维护成本，时间，实现复杂度 等各方面综合考虑。。也许将来可能会支持，但短期你只能强绑定 windows 平台走 msvc 的包，mingw 平台走 mingw 包，cross 平台，走任意 toolchain 包。 哥们，你这不容易啊，单人维护这么多年

Organization/Company: wiqun Website: https://www.wiqun.com/ Country: China Contact: [email protected] Usage scenario: Using NetPoll to build pub-sub message system Status: development

这个应该不太好做。需要兼容go原生的context

> `AsyncXX` 函数和回调函数返回的 error 通常是系统调用的错误，系统调用报错的概率极小，可以认为这些函数返回的错误永远是 error == nil，但理论上还是有可能 err != nil，判断一下就行。 > > > 如果AsyncWritev返回错误，是否内部的回调函数一定不会执行，如果asyncWritev不返回错误，内部的回调函数一定执行? > > 没有必然关系，不能依赖这个逻辑关系。 这里的api设计令人很困惑，令人难以理解: ``` func (c *conn) AsyncWrite(buf []byte, callback AsyncCallback) error { if...

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

> 这里的内存管理是指什么？能具体说一下吗？ 基于gnet去实现框架的批量发送功能时，如果考虑内存复用，等特性，就需要自己去管理pool. 类似于netpoll的mux的writequeue，相当于gnet也有自己的writequeue了.

> 用 `sync.Pool` 就能实现一个简单的内存池了，结合 asyncwritev 的回调函数可以方便地回收内存到 pool，自己管理这部分在我看来也不麻烦啊，还是说你还想要其他的东西？能不能用(伪)代码具体表示一下你的确切需求？ 起因是希望能实现oneway形式的通讯模式的sub-pub system，需要提升单个tcp连接上的传输性能。 使用writev系统调用来传输数据是个很好的选择.但是内存管理比较麻烦。类似于并发安全的writequeue buffer， 可以对接writev系统调用。 这种内存管理有两个用途，一个是单个tcp连接上的多路复用，另外一个是应用级别的内存管理