为何Linux下poll/epoll会将accept()视为read()类操作触发EPOLLIN？

对于监听套接字而言，EPOLLIN事件触发时可以调用accept()，本质是因为不同类型的文件描述符，"可读"的定义存在差异，手册里的描述只是通用表述，具体到监听套接字有特殊的行为约定。

1. 监听套接字的"可读"特殊含义 #

当套接字通过listen()进入监听状态后，它的核心作用是接收新的TCP连接。此时所谓的"可读"，并不是指有普通数据流可以用read()读取，而是指TCP的已完成连接队列中存在等待处理的新连接——这时候调用accept()不会阻塞，就像普通套接字有数据时read()不会阻塞一样。

2. EPOLLIN的广义定义 #

手册中对EPOLLIN的定义是：

EPOLLIN
关联文件可执行read()操作。

这个定义是通用层面的描述，并没有限定read()的具体行为。对于不同类型的fd（文件描述符），"可执行read()"的场景完全不同：

• 普通文件：只要文件指针未到末尾，就可执行read()
• 管道/普通套接字：有数据等待读取时，可执行read()
• 监听套接字：有新连接等待accept()时，等价于"可执行读取操作"，因此会触发EPOLLIN

3. Unix/Linux网络编程的长期约定 #

这种行为是Unix/Linux网络编程中默认遵循的规则，poll/epoll这类多路复用机制都会将监听套接字的"有等待连接"状态映射为POLLIN/EPOLLIN事件。虽然手册没有直接把accept()和read()绑定，但这种行为是明确且被广泛认可的，几乎所有多路复用服务器示例都会采用这种实现方式。

内容的提问来源于stack exchange，提问作者Sgg8