和别的语音相比好在那里了
1
yulon 259 天前
谁说的?
|
2
gowk 259 天前 via iPhone
先说是不是 再说为什么
|
3
wkong 259 天前
如果完美了,我们开源项目就没必要再重新封装了。
|
4
julyclyde 258 天前
你这就跟“中国专家”的“论证”似的
先确定结果,再找论据 |
5
flyqie 258 天前 via Android
谁说的?
给个出处? |
6
lance6716 258 天前 via Android
谁说的去问谁
|
9
lysS 257 天前
确实封的挺好,还和 runtime 绑定了;但是它的 raw 相关的太少了,还得用 x/net
|
10
huangwei8ku 257 天前
完美其实谈不上的,只是在你的业务场景里面比较合适,golang 官方其实想实现的是一种 goroutine-per-connection 这样的极简的开发模式给使用者。这种开发模式极大地降低了开发者编写网络应用时的心智负担,且借助于 Go runtime scheduler 对 goroutines 的高效调度,不论从适用性还是性能上都足以满足绝大部分的应用场景。所以才说在你的业务应用场景里可能发挥的好。另外 net 包也只是调用,实现 epoll 的实际上是 runtime 包里面的 netpoll_epoll.go
|
11
wkong 257 天前
|
12
777777 257 天前
net 包是 bio ,但 go 的协程是 nio ,所以应该是 go 原生封装了 epoll
|
14
1423 257 天前
我是十分认同的
|
15
wkong 257 天前
@v2exblog 原生的其实底层也是用的 epoll ,但是到上层后必须要一个 goroutine 一个连接,我们是即时通讯的项目,如果 100 万同时在线,那就需要 100 万个 goroutine ,消耗还是很大的。
|
17
chronos 257 天前
怎么在这里也搞知乎式的问题
|
19
securityCoding 255 天前 via Android
真实 rpc 场景消耗还是太大了,一般还是会重新封装一层复用协程
|
20
shaoyie 249 天前
确实组织的很完美,再结合 g 的调度,以及 timer 的结合,能让它表现出很强的性能和过程化开发能力(虽然说单个 poller 有些许不如意,但整体还是很强悍的,不信的同学可以 自己测试一下,我这有份测试代码,可以参考 https://github.com/shaovie/goev/blob/main/example/nettcp.go )
可以研究一下 SetReadDeadline 的实现,感受其奥妙 |