在Linux上使用阻塞套接字时，send()是否有理由返回少于请求的其他，而不是中断但部分成功的send()系统调用？
我知道这可能是非常实现的定义，即使没有任何已安装的信号处理程序，依赖于该行为也可能是非常危险的（因此中断系统调用的原因）。我可能会绕发送电话直到完成;但是，如果有关于此事的任何官方消息，我将能够避免这种情况。
Why is it assumed that send may return with less than requested data transmitted on a blocking socket?提出了同样的问题，结果不确定：中断的系统调用被提及作为短返回计数的示例，但仍然不清楚完整的TCP发送缓冲区是否会导致部分发送或{{ 1}}只会阻塞，直到缓冲区中有足够的空间。
答案 0 :(得分：4)
一般情况下，如果发送缓冲区包含一些空间，但对于整个发送请求来说还不够，那么它将尽可能多地发送，然后返回实际添加到缓冲区的数量 - 一个简短的写入。
现在你可以说，阻塞（在阻塞套接字上）更有意义，但它不是历史的原因 - TCP基于UNIX管道，这就是UNIX管道的工作方式。主要原因是它使得极端情况（在内核中）更容易 - 您不必担心阻止系统调用in the middle做某事;它要么做某事并立即返回，要么什么也不做，并阻塞直到某个事件（此时内核从头开始重试）。如果有人试图在单次写入中写入超过最大缓冲区大小（否则可能导致死锁），您不必担心会发生什么。