在Linux上使用阻塞套接字时，send()是否有任何原因返回的值小于请求值，其他是否有任何理由返回中断但部分成功的send()系统调用？
我知道这可能是非常定义的实现，即使没有任何安装的信号处理程序，依赖这种行为也可能是非常危险的（因此也是系统调用中断的原因）。我可能会循环发送呼叫，直到完成；然而，如果这件事有任何官方说法，我可以避免。
为什么假设send可能返回的数据少于阻塞套接字上传输的请求数据？提出了同样的问题，但没有得出结论：中断的系统调用被提到作为短返回计数的一个例子，但仍不清楚是完整的TCP发送缓冲区会导致部分发送，还是send()会阻塞，直到缓冲区中有足够的空间。
通常，如果传输缓冲区包含一些空间，但不足以容纳整个发送请求，那么它将尽可能多地发送，然后返回实际添加到缓冲区的数量——一个短写。
现在，您可能会认为阻塞（在阻塞套接字上）更有意义，但它没有阻塞的原因是历史原因——TCP基于UNIX管道，这就是UNIX管道的工作方式。主要原因是它使（内核中的）角落情况变得更容易——您不必担心阻止系统调用in the middle执行某些操作；它要么做一些事情并立即返回，要么什么也不做并阻塞，直到某个事件发生（此时内核从头开始重试）。如果有人试图在一次写入中写入超过最大缓冲区大小的内容（否则可能会导致死锁），您不必担心会发生什么。