为什么说 golang， net 包是对 epoll 的完美封装

谁说的？

先说是不是 再说为什么

如果完美了，我们开源项目就没必要再重新封装了。

你这就跟“中国专家”的“论证”似的
先确定结果，再找论据

谁说的？

给个出处？

谁说的去问谁

@wkong 还要封装啥 go 不是有个装门的 M 来挂载要 io 的 G 的 epoll 事件吗，虽然看起来是 bio

@wkong 介绍一下哪个开源项目重新封装了 epoll ，学习下

确实封的挺好，还和 runtime 绑定了；但是它的 raw 相关的太少了，还得用 x/net

完美其实谈不上的，只是在你的业务场景里面比较合适，golang 官方其实想实现的是一种 goroutine-per-connection 这样的极简的开发模式给使用者。这种开发模式极大地降低了开发者编写网络应用时的心智负担，且借助于 Go runtime scheduler 对 goroutines 的高效调度，不论从适用性还是性能上都足以满足绝大部分的应用场景。所以才说在你的业务应用场景里可能发挥的好。另外 net 包也只是调用，实现 epoll 的实际上是 runtime 包里面的 netpoll_epoll.go

@llwwbb7 https://github.com/WuKongIM/WuKongIM

net 包是 bio ，但 go 的协程是 nio ，所以应该是 go 原生封装了 epoll

@wkong 大佬，请问为什么要重新封装 epoll

我是十分认同的

@v2exblog 原生的其实底层也是用的 epoll ，但是到上层后必须要一个 goroutine 一个连接，我们是即时通讯的项目，如果 100 万同时在线，那就需要 100 万个 goroutine ，消耗还是很大的。

@wkong 学到了谢谢大佬解答

怎么在这里也搞知乎式的问题

@wkong 都用 go 了，高负载时不得上多机器分布式吗

真实 rpc 场景消耗还是太大了，一般还是会重新封装一层复用协程

确实组织的很完美，再结合 g 的调度，以及 timer 的结合，能让它表现出很强的性能和过程化开发能力（虽然说单个 poller 有些许不如意，但整体还是很强悍的，不信的同学可以 自己测试一下，我这有份测试代码，可以参考 https://github.com/shaovie/goev/blob/main/example/nettcp.go ）
可以研究一下 SetReadDeadline 的实现，感受其奥妙