someview

I have the same problem.vps ubuntu18.04,use root to run sh,but mentioned 'cannot read MSR 0x000001a4 FAILED TO APPLY MSR MOD, HASHRATE WILL BE LOW '

我们利用gnet实现的ws框架，性能4核的时候是1核的2倍多一点，很好奇这个cpu 亲和性是怎么做的

这个问题还没关闭啊，我们也有这个需求，采用gnet来作为quic协议的底层连接驱动库。不匹配的地方是quic没有提供asyncwrite，这和gnet当前的方式不太匹配。另外一点是，gnet是把addr 绑定在conn上面的， 而quic协议addr本身是可变的，这要求把addr从conn中解放出来

这个问题还没关闭啊，我们也有这个需求，采用gnet来作为quic协议的底层连接驱动库。不匹配的地方是quic没有提供asyncwrite，这和gnet当前的方式不太匹配。另外一点是，gnet是把addr 绑定在conn上面的， 而quic协议addr本身是可变的，这要求把addr从conn中解放出来

> 代码中没有使用conv当唯一标识，而是使用ip和port作为唯一标识。当客户端切换网络或者挂上VPN时，IP会改变，这样就认为是一个新连接了，后续发送的包无法和客户端对应上。这个问题需要如何处理呢？ 目前也准备做这件事情，quic协议里简单提到负载均衡器使用其中的perfer address port来做负载均衡,当然也可以使用previous connectionId来作负载均衡

> 其实就是 `SetReadDeadline`，timing-wheel 不够精确、tick间隔越低越精确但是就可能empty loop更多，所以并不是很划算，定时器这种优先级队列场景还是 heap timer 更好些。有兴趣可用参考下我这的实现： https://github.com/lesismal/nbio/blob/master/conn_unix.go#L223 评论区出人才

> @manchurio 我们内部调研，uring 对 RPC 场景的改善很少，尤其是小包场景。如果netpoll支持 uring，代码改造挺大，收益却不大，所以目前暂缓在现有代码基础上，支持 uring 了。但是会在后面的大版本重构中，把这个功能考虑进来。 也就是说，对大包的场景改进比较大了，是这种意思吗

I have find other mistake in the client code: ``` func (c *connection) SendRequest(requestID uint64, req *pb.BaseCommand, callback func(command *pb.BaseCommand, err error)) { c.incomingRequestsWG.Add(1) defer c.incomingRequestsWG.Done() state := c.getState() if...

The code may use chan any to instead multi select cases. The multi cases may cause performance issue. And chan any interface would have better performance for this. ``` func...

the Receive is pretty confused with me. Why for range is needed ``` func (c *consumer) Receive(ctx context.Context) (message Message, err error) { for { select { case