hopehook

> go1.14提示 missing function body > > 代码如下：main3.go package main > > import ( "fmt" ) > > var helloWorld = "你好, 世界" func println(s string) { fmt.Println(s) } func...

I can reproduce it stably now. (go version go1.19 darwin/amd64) Output syscall.ptrace: nosplit stack over 792 byte limit syscall.ptrace grows 120 bytes, calls syscall.ptrace1 grows 200 bytes, calls syscall.syscall6 grows...

CC @aclements

I found that the test case can be passed by `go test -gcflags='-l'` test. (maybe the problem is caused by optimization of inlining)

连接池是满的, 意味着着空闲的连接比较多. 如果不实时更新连接池, 会让老的连接在 Get 的时候自动淘汰掉. 当然, 在 Put 主动淘汰老连接, 也是可以的, 可能好处不是很明显.

pr 已经提了，后续我会继续关注，如果有任何问题，我再反馈。

1 关于 Ping 这个 ping 本身不是强制的, 如果有这个机制支持, 是可以解决这个问题的. (当然, 会影响连接池的高效, 连接池的目的就是避免 tcp 3 次握手, 4 次挥手的代价. 而 ping 在这里实际上也是一个报文, 会有 2 次数据传输交互的开销) 2 关于 Connect 为了高效, 和在 thrift 中使用连接池, 我多加了这个...

> 1、ping这个方法没有问题，在使用时检测连接是否有效 有时候也是需要的，只是我觉得，这个判断的操作应该放在用户端，像你封装的这个Call > 2、看了下你这个处理，通过maxBadConnRetries，alwaysNewConn 控制 这个学习了 所以 Ping 这个方法我没有暴露出来, 不是强制的. (如果您觉得多余, 移除也是没问题的) maxBadConnRetries，alwaysNewConn 控制这个实际上是借鉴的 golang 标准库的做法, 目前处理这种连接失效的最好做法可能就是调用失败的时候, 重试, 重试失败的时候重新建立连接. 如果这么做的话, 我就需要一个 Connect 方法, 要不然没法建立新连接.

从 Get 方法中把 Connect 拆出来，使得用户可以创建新的连接。 可能的应用场景： 1，Get 之后，发现连接池的连接失效，通过 Connect 重连进行操作，如果多次重试还是失效，说明 server 确实不可用。如果 server 只是短暂重启，Connect 可以支持这种场景，清理失效连接。 2，初始化的时候，连接池的数量设定的过少，希望后期人为增加连接数量。可以 Connect，然后 Put。