使用带有"select"功能的非阻塞套接字有什么好处？

Question

我正在Linux中编写一个服务器,它必须支持来自多个客户端的同时读/写操作.我想使用select函数来管理读/写可用性.

我不明白的是:假设我想等到套接字有可读数据.它将阻塞的选择状态的文档,直到有可读取的数据,并且读取函数不会阻塞.

所以如果我使用select并且我知道read函数不会阻塞,为什么我需要将套接字设置为非阻塞？

Answer 1

可能存在套接字被报告为就绪的情况,但是当您检查它时,它会更改其状态.

一个很好的例子是接受连接.当新连接到达时,会报告侦听套接字已准备好进行读取.当你接到呼叫接受时,在发送任何内容之前和我们呼叫之前,连接可能会被另一方关闭accept.当然,这种情况的处理依赖于操作系统,但是可能accept只会阻塞直到建立新的连接,这将导致我们的应用程序等待无限期的时间来阻止处理其他套接字.如果您的侦听套接字处于非阻塞模式,则不会发生这种情况,您将获得EWOULDBLOCK或其他一些错误,但accept无论如何都不会阻止.

以前有些内核(我希望它现在已经修复)是一个有趣的UDP和UDP错误select.当数据报到达select时,套接字被唤醒,数据报被标记为准备好读取.数据报校验和验证被推迟,直到用户代码调用recvfrom(或某些其他能够接收UDP数据报的API).当代码调用recvfrom并且验证代码检测到校验和不匹配时,数据报将被简单地丢弃并recvfrom最终被阻塞,直到下一个数据报到达为止.可以在此处找到解决此问题的补丁之一(以及问题描述).