epoll在多线程中的应用-EPOLLEXCLUSIVE和REUSEPORT(一)

最新推荐文章于 2024-03-07 19:27:21 发布

dream0130__

最新推荐文章于 2024-03-07 19:27:21 发布

阅读量3.8k

点赞数 10

分类专栏：线程 OS

本文链接：https://blog.csdn.net/dream0130__/article/details/104009426

版权

本文探讨了在多线程环境下使用epoll时遇到的file descriptor和kernel file description生命周期问题，以及特定TCP listen fd的accept问题。文章分析了EPOLLEXCLUSIVE和SO_REUSEPORT选项如何解决惊群效应，提升多核环境下Web服务器的性能，并讨论了它们的优缺点和使用场景。

摘要由CSDN通过智能技术生成

以下均为对epoll在多线程中的使用的一些笔记，如果有不对的地方，烦请指出

主要对于我所遇到的问题进行讨论，不会讨论代码如何改写，探讨如何解决这个问题

一.引言

这些问题均是我在编写我的Web服务器遇到的,我在编写多线程Web服务器的时候,思考如何利用多核的优势来编写Web服务器.在学习了muduo网络库之后，我的先前一个版本的Web服务器采用这种方式,一个master线程+多个工人线程,但是我觉得在高并发的情况下只有一个线程可以accept这无疑限制了accept吞吐量,并不算利用多核优势.进而引发了我对于在多线程中如何高效合理的使用epoll有了探索.

二．epoll file descriptor 和　kernel file description 生命周期的问题

`谈及这个问题,我们需要了解

(1) 进程维护file descriptor表　，每个fd包含
fd 标志
指向内核的file descriptor表象的指针
(2)内核维护所有打开文件的file description表,每一个表都包含文件的状态标志
当前文件的offest
文件状态标志(读,写,阻塞，非阻塞)
指向该文件v节点

每个进程的task_struct 包含了用于完全应该工作的成员

struct task_struct {
   
	//文件系统信息
	int link_count , total_link_count;
	---
	struct files_struct * files;　//打开的文件信息
	---
}

struct files_struct {
   

	-----
	atomic_t count