When will send() return less than the length argument?

Question

When using blocking sockets on Linux, is there any reason for send() to return less than what was requested, other than an interrupted, but partially successful send() syscall?

I'm aware that this is possibly very implementation defined, and that it would probably be very dangerous to rely on that behavior even without any installed signal handlers (and thus reasons for interrupted syscalls). I'll probably loop around the send call until completion; however, if there were any official word on the matter, I would be able to avoid that.

Why is it assumed that send may return with less than requested data transmitted on a blocking socket? was asking the same question, with inconclusive results: Interrupted syscalls are mentioned as an example for a short return count, but it's still unclear whether a full TCP send buffer would cause a partial send or the send() would just block until there is enough room in the buffer.

Answer 1

In general, if the transmit buffer contains some space, but not enough for the entire send request then it will send as much as it can and then return the amount actually added to the buffer -- a short write.

Now you could argue that it would make more sense to block (on a blocking socket), but the reason it doesn't is historical -- TCP is based on UNIX pipes, and that's the way UNIX pipes worked. The main reason is that it makes corner cases (in the kernel) easier -- you don't have to worry about blocking a system call in the middle of doing something; it either does something and returns immediately or does nothing and blocks until some event (at which point the kernel retries it from scratch). You don't have to worry about what happens if someone tries to write more than the maximum buffer size in a single write (which might otherwise cause a deadlock).