select系统调用使用疑问：何为socket I/O就绪 对端断连时select为何返回成功

select 对就绪状态的判定核心逻辑，和很多人直觉里的“有数据能读/能写”并不一致：它的判断标准是对目标文件描述符执行对应方向的I/O操作时，调用不会进入阻塞挂起状态，可立刻得到返回结果。对于纳入readfds集合的socket，只要满足以下任意一种情况，就会被标记为可读就绪：

• socket内核接收缓冲区中存在已收到、未被应用层读取的有效数据，此时read调用可直接返回数据，不会阻塞
• 对端已经通过FIN包完成连接终止流程，此时对本端socket执行read操作，会立刻返回0（代表读取到EOF、连接已终止），不会阻塞等待网络数据
• 处于监听状态的socket上有已完成三次握手、排队待处理的新连接，此时accept调用可直接拿到新连接fd，不会阻塞
• socket上产生了需要通知应用层的异步错误，此时对该socket执行read操作会直接返回错误标记，不会阻塞

你之前的认知偏差，是把“socket可读就绪”窄化为“socket内核缓冲区有有效业务数据可读”。实际上连接终止产生的EOF事件，是最典型的可读就绪场景之一：
当对端正常关闭连接时，内核会向本端发送FIN段，本端的协议栈会将对应socket标记为“读就绪”——因为此时应用层发起read操作，协议栈不需要等待任何网络传输，就能立刻把“对端连接已终止”的状态通过read返回0的形式告知应用，整个过程没有任何阻塞环节。
这种情况下select自然会在检测到该标记后立刻返回，把对应fd的就绪状态告知应用，完全不会等到超时时间耗尽。你实际测试到的“select返回1、read拿到0”的结果，是完全符合select设计语义的标准行为。 #

你目前的循环逻辑存在一个容易触发死循环的漏洞：当对端关闭连接、read返回0时，你的代码仅判断了readbytes < 0的错误分支，没有处理readbytes == 0的EOF场景。此时received_len的值不会增长，循环会持续调用select、read——而select每次都会立刻返回该socket就绪、read每次都会返回0，最终形成无意义的空转死循环。
正确的处理逻辑需要在read返回值为0时，直接跳出循环、执行对应连接的清理流程。 #

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