Andy Pan
Andy Pan
This is a breaking change, I think we shouldn't rush into it.
Not supported yet, but I think it's reasonable to implement this feature.
`AsyncWrite()` writes bytes asynchronously, so I don't think that it can return the number of written bytes synchronously. Furthermore, there is a promising buffer management inside `gnet` that ensures all...
看起来这个问题很长时间没有复现了，暂时关闭这个 issue。如果再复现可以随时重新打开。
直接通过 syscall 设置不行吗？
通过系统调用 `setsockopt` 设置 tos 即可，可以参考：https://cs.opensource.google/go/x/net/+/master:ipv4/genericopt.go;l=21;drc=c63010009c802314a29324ce49987897f9838e29?q=settos&ss=go%2Fx%2Fnet
你们用的是 1.x 版本吧，conn 应该没有 `Fd()` 返回 fd，我理解是不是新增一个 API 返回 fd 给你，你自己去设置就行了？
> Test example: ~100 kb TCP packet > > **conn.Write(), 0.1 ms** > > ``` > log.Println("start") > bytesWritten, err = conn.Write(tcpBytes) > log.Println("stop") > ``` > > **conn.AsyncWrite(), 40...
目前 `gnet` 的内部是无锁的架构设计，所以目前 `asyncWrite` 是并发安全地写数据的唯一方法，如果这种方式确实有性能瓶颈的话，那可能这种架构确实需要重构一下支持并发实时回写数据。不过你确定是因为这个才导致延迟的吗？我看你的 QPS 挺大的了，你有没有试过用 go `net` 做过对比测试呢？
> 请问有什么办法做到线程安全的实时写回 client 吗？ 你可以通过 `c.Fd()` 获取连接的 fd，然后直接通过系统调用 `syscall.Write` 回写数据。这种方式的话你就必须自己管理 buffer，没写完的数据保存起来然后下次再回写的时候要先写上次遗留的数据。而且，如果你用这种方式的话就只能用这一种方法，而不能和 `gnet` 的 `c.Write/c.AsyncWrite` API 混用。