someview

the scenario is different. go standard map is not concurrent map. Now the haxmap use lock free list to ensure that the map is concurrently safe，different from shard map with...

> 根本上，限流是有损的。但是你真正想要的只是内存别占用太猛，并不需要真的拒绝那些连接本身。 宏观上的资源控制， 当然，连接本身也可以作为一种资源。就像http2maxStreamNum一样，为了保证资源不被耗尽. 在单向无反馈机制的设计中，对每一层自己的管理的资源应该是可以控制和观察的.

> @someview 现在就是可以做的呀，你 onConnect onDicConnect 接口可以控制连接数 不仅仅是这方面，目前我们切了一个分支，做了三个改动，来做这件事情: 1. 服务端new的时候，添加了一个参数, 来控制节点参数分配的节点大小： ``` // WithNoCopyPageSize sets the connection read buffer nocopy page size. // // It means when read trigger,the size of...

> @someview 第二点我还是建议通过 malloc 的方式来维护长度。因为flush返回的长度一定等于malloc mallocack后真正用户写入的长度。这个因为是用户主动写入的，用户肯定知道。 > > 第一点，现在都开放了内部参数调优了https://github.com/cloudwego/netpoll/pull/349/files 如果做写入的流控的话，就需要在shardqueue flush之前，获取到to flush的长度. flush完毕以后，恢复缓冲区大小

我们对netpoll有几个改动的需求，是否可以考虑添加这个，让linkedbuffer变得可以复用： ``` // SliceIntoReader implements Connection. func (c *connection) SliceIntoReader(n int, r Reader) (err error) { if err = c.waitRead(n); err != nil { return err } return c.inputBuffer.SliceIntoReader(n, r)...

> @someview 写入和读不同，读是被动行为；写入是主动行为，写入的流控应该在应用层调用 Write/Malloc 的时候控制，否则即便netpoll不写入，它也还是在内存里，还是有问题的。 写入的行为确实是写入方自己限流的

好久没看netpoll，搞忘关issue了, 发送消息的时候需要啊，内部rpc并发发送

照这个逻辑，devlop分支也有这个bug，在这里提个issue.

> @someview 你 panic stack 能贴完整吗？error != nil 时，n 为0，讲道理也不会panic 这个很好触发，只要让操作系统因为tcp缓冲区溢出的同时，还有并发读写。eventloop就panic了。具体的代码可能等我和前同事沟通一下，跑路了

这比官方最新提供的解决方案还好吗? ``` func strToBytes(str string) []byte { return unsafe.Slice(unsafe.StringData(str), len(str)) } func btsToString(bts []byte) (str string) { return unsafe.String(unsafe.SliceData(bts), len(bts)) } ```