c - read() 是否位于 Linux(OSX、FreeBSD)以外的平台上的非阻塞套接字 "greedy"上？

Question

考虑以下对 read() 的调用在非阻塞流模式套接字 ( SOCK_STREAM ) 上:

ssize_t n = read(socket_fd, buffer, size);

假设远程对等方不会关闭连接，也不会关闭其写入的一半连接(从本地角度来看，读取的一半)。

在 Linux 上，在这些情况下的短读取 ( n > 0 && n < size ) 意味着内核级读取缓冲区已耗尽，并且立即后续调用通常会失败，并显示 EAGAIN/EWOULDBLOCK (除非新数据成功到达两个调用之间，否则它将失败)。

换句话说，在 Linux 上，调用 read()将始终消耗立即可用的所有内容，前提是 size足够大。

对于 write() 也是如此，在 Linux 上，短写入始终意味着内核级缓冲区已填满，并且立即后续调用可能会失败，并显示 EAGAIN/EWOULDBLOCK .

问题 1:在 macOS/OSX 上也能保证这一点吗？

问题 2:FreeBSD 上也能保证这一点吗？

问题 3:POSIX 是否要求/保证这一点？

我知道这在 Linux 上是正确的，因为 epoll 的手册页中有以下注释。 (第 7 节):

For stream-oriented files (e.g., pipe, FIFO, stream socket), the condition that the read/write I/O space is exhausted can also be detected by checking the amount of data read from / written to the target file descriptor. For example, if you call read(2) by asking to read a certain amount of data and read(2) returns a lower number of bytes, you can be sure of having exhausted the read I/O space for the file descriptor. The same is true when writing using write(2). (Avoid this latter technique if you cannot guarantee that the monitored file descriptor always refers to a stream-oriented file.)

编辑:作为问题的动机，考虑这样一种情况，您希望同时处理多个套接字上的输入，并且无论出于何种原因，您希望通过依次完全耗尽每个套接字的内核缓冲区来实现此目的(即“深度优先”而不是“广度优先”)。显然，这可以通过在就绪套接字上重复读取直到失败并显示 EAGAIN 来完成。/EWOULDBLOCK ，但是如果前一次读取很短，那么最后一次调用将是多余的，而且我们知道短读取肯定会耗尽。

Answer 1

由Posix保证:

data shall be returned to the user as soon as it becomes available.

...因此在您提到的所有其他平台上，以及 Windows、OS/2、NetWare，...

任何其他实现都是毫无意义的。