在 Linux 上使用阻塞套接字时，send() 是否有任何理由返回少于请求的值，其他而不是中断但部分成功的 send() 系统调用？
我知道这可能是非常实现定义的，即使没有安装任何信号处理程序（以及因此中断系统调用的原因），依赖该行为也可能非常危险。我可能会循环发送调用直到完成；但是，如果有任何官方消息，我将能够避免这种情况。
Why is it assumed that send may return with less than requested data transmitted on a blocking socket? 提出了同样的问题，但结果不确定：中断的系统调用作为返回计数短的示例被提及，但仍不清楚完整的 TCP 发送缓冲区是否会导致部分发送或send() 会只是阻塞直到缓冲区中有足够的空间。
【问题讨论】：
一般来说，如果传输缓冲区包含一些空间，但不足以满足整个发送请求，那么它将尽可能多地发送，然后返回实际添加到缓冲区的数量——一个简短的写入。
现在您可能会争辩说阻塞（在阻塞套接字上）更有意义，但它不是历史原因 - TCP 基于 UNIX 管道，这就是 UNIX 管道的工作方式。主要原因是它使极端情况（在内核中）更容易——你不必担心阻塞系统调用in the middle 做某事；它要么做某事并立即返回，要么什么都不做并阻塞直到某个事件（此时内核从头开始重试）。如果有人尝试在单次写入中写入超过最大缓冲区大小（否则可能导致死锁），您不必担心会发生什么。
【讨论】：
send() 的手册页显示 When the message does not fit into the send buffer of the socket, send() normally blocks, unless the socket has been placed in nonblocking I/O mode. In nonblocking mode it would fail with the error EAGAIN or EWOULDBLOCK in this case. 它似乎没有将函数记录为返回除 len 参数以外的任何内容（或 -1 错误)。