我正在通过 TCP/IP 套接字读取数据流。流负载非常不均匀。有时每秒有大量数据到达，有时一个小时没有数据。在长时间不活动的情况下（远程服务器没有数据，但连接仍然在线）我的程序应该采取一些措施。
我正在使用 select() 实现超时。它告诉我是否有数据准备好，但我不知道在不导致 read() 阻塞的情况下我能读多少。阻塞是不可接受的，因为它的持续时间可能比我需要的超时时间长得多。
为了提高效率，流被读入大缓冲区，read() 调用提供了该缓冲区大小。
如果要填充的缓冲区大于套接字中当前可用的数据量，read() 是否会在 select() 之后阻塞？
【问题讨论】：
实际上它不应该阻塞（这就是 select() 的用途！），但事实上，它可能，非常例外。通常， read() 应该返回您指定的最大字节数，其中可能包括零字节（这实际上是一个有效的事情发生！），但它不应该在之前报告就绪后阻塞。
不过，请参阅 Linux select 手册页：
在 Linux 下，select() 可能会报告一个 套接字文件描述符为“准备好 阅读”，尽管如此 后续读取块。这可以 例如，当数据有 到了但检查有错 校验和并被丢弃。也许有 是文件的其他情况 描述符被虚假报告为 准备好。因此使用起来可能更安全 O_NONBLOCK 在不应该的套接字上 块。
【讨论】：
select()，但将套接字设置为非阻塞，当select() 表示可读时，调用read() 直到它返回EAGAIN。
recv 将套接字标记为就绪会 阻塞。诚然，这是一个罕见的事件，但可能且合法。
write 一个文件然后 read 它回来，你会得到你写的相同的字节。当然，如果其他人在此期间覆盖了该文件，那是不正确的……但否则它是正确的。 O/S 不能随意地神奇地使你的套接字不可读，就像神奇地破坏你的文件一样。我有点惊讶有人会尝试以其他方式争论。 （甚至 Linux 开发人员也同意这违反了 POSIX；他们只是说这是故意违反速度。）再一次：在 Linux 之前没有 Unix 有过这样的行为。
有O_NONBLOCK 可以通过fcntl/F_SETFL 设置并且应该导致非阻塞read。
【讨论】：
select() 将等待非阻塞描述符上包含数据（或文件结尾）。
readfds 中列出的那些将被监视以查看字符是否可供读取（更准确地说，查看读取是否不会阻塞；特别是文件描述符在文件结束时也准备好了）”。我想这是在read 即使没有可用字符时也会立即返回的情况下修复原始句子的方法。顺便说一句，不要忘记select 可能会在描述符上的任何事件之前被信号中断，否则会发生超时。
一个阻塞的文件描述符会阻塞在 read() 上，直到有东西要读取——可能是一个字节或你的整个请求。如果没有可读取的内容，非阻塞描述符不会在 read() 上阻塞。 Select() 不是 read()。它基本上使进程进入睡眠状态并监视文件描述符，包括非阻塞描述符。当其中一个描述符有活动（或超时期限到期）时，选择返回，您可以读取数据，或者在超时的情况下执行其他操作。
所以你有两个不同的问题。 (1) 在没有数据的情况下，你想“采取一些行动”。那是选择超时。 (2) 一旦有了数据（通过选择通知），您就不想阻止读取。这就是非阻塞模式。当您在非阻塞读取上获得 EAGAIN 时，您将循环回选择和/或“采取一些行动”并循环回选择。
【讨论】：
不，read() 将读取到指定大小并返回实际读取的字节数，可能会更少。
【讨论】：
read 将阻塞如果根本没有可用的字节，并且如果描述符处于阻塞模式，它还不是文件结尾，我记得。
你可以使用默认不阻塞的recv()（如果没有指定标志MSG_WAITALL）
【讨论】：