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