这是一个创建于 500 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近阅读了一些 epoll 相关的代码，发现其定义了多个 epoll 线程
我很疑惑，epoll 不是可以进行 io 多路复用的吗，单个线程不就足够了
是为了平衡 io 的开销吗？
而且多个 epoll 线程的话，如何确定哪一个可以 accept 新连接
还请 v 友解答一下
 |
1
FabricPath 2023-07-11 11:16:55 +08:00
不懂 epoll ，不过单线程去 accept ，那短连接的瓶颈就在这单个线程了，毕竟 accpet 之后还要分发到其他线程去处理
|
 |
2
xycost233 2023-07-11 11:19:22 +08:00
如果你 epoll 事件会进行 CPU 密集型操作的话建议把操作交给另一个线程，epoll 作为分发器把任务分给其他的线程
|
 |
3
wdf1286 2023-07-11 11:29:39 +08:00
读写 fd 有它固有的消耗，无论你是 select 还是 epoll ，单线程跑满了就只能多开线程
|
 |
4
nightwitch 2023-07-11 11:30:35 +08:00 via Android
one loop one thread 和 one loop all threads 只是两种不同的编程模型，取决于 epoll 接收到事件后怎么处理。没有绝对的优劣
|
 |
5
buhuiqizi 2023-07-11 11:31:54 +08:00
再快也是有极限的吧
|
 |
6
johnshopkins 2023-07-11 12:57:34 +08:00
参照 nginx ，epoll_wait 专门一个 master 进程可以用作套接字的 三次握手、四次挥手；和读、写数据包的事件通知——仅仅做通知。
真正耗费时间的是读、写数据包和期间的业务处理过程，所以放到单独 worker 下最佳。可以显著避免阻塞 epoll_wait 进程。想要 高并发必须要做的。 |
 |
7
julyclyde 2023-07-11 17:56:26 +08:00
@nibaozhu 在进程这个层次不存在三次握手。内核做好 TCP 连接之后，才轮到 userland 的 accept/epoll ready
|
 |
8
e7 2023-07-11 18:50:52 +08:00
多路复用是相对于每次只能处理一个连接的编程模式来说的（单个线程），都可以使用多线程增加处理能力
|
 |
9
ysc3839 2023-07-11 21:34:22 +08:00 via Android
多线程一般是为了充分利用 CPU 性能，尤其是处理逻辑里涉及 CPU 密集的代码时
|
|
10
johnshopkins 2023-07-24 16:17:20 +08:00
@julyclyde 不是 listen 完，有客户上来内核就自动做好 TCP 连接。这里必须由用户的进程主动调用 accept 函数（不管异步与否），然后由中断切换到系统调用 sys_accept4 返回客户机地址及套接字，这个过程没有 epoll 也是可以的，epoll 只是提高了效率，不是必要条件。
|
|
11
johnshopkins 2023-07-24 16:21:22 +08:00
epoll_wait 返回后，可以遍历触发事件的列表，结构体里面包含了套接字，（如果是 listen 套接字就说明有新晋的客户端需要建立新连接，如果是之前已经建立连接的 对端套接字，那这种情况下根据是可读可写标志做判断，如果读到零，说明客户机需要关闭连接，这种需要调用 shutdown 关闭套接字）。
|
Select Language