这是一个创建于 470 天前的主题，其中的信息可能已经有所发展或是发生改变。
和别的语音相比好在那里了
 |
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 的实现，感受其奥妙 |
Select Language