[Spread-users] Re: SP_scat_multicast not sending the entire message

[Tim Peters]

[Yair Amir]
> My understanding is that if it is a non-blocking call (which in the
> case of the Spread library it should be as far as I know) then the call
> should not return with a partial write.
>
> I remember that some very old Linux version had a bug in this regards which
> I pointed to Don Becker and he fixed, but that was many years ago.
>
> So, in my opinion, if a partial write occurs on a blocking call
> then that is a bug in the OS. What am I missing?

It may be that current POSIX-spec blocking stream sockets are required
to send all-or-nothing, but actual behavior isn't so nice, in part
because Berkeley left so much about sockets ill-specified.

In Python we gave up, and just documented that Python's
socket.send(data) may do a partial send:

http://mail.python.org/pipermail/python-bugs-list/2000-September/001762.html

As that says, there appears to be nothing in Stevens ("Unix Network
Programming") to back the idea that blocking send() is all-or-nothing.
 Everything we learned at the time was obtained by running programs
and watching what happened, and partial sends were a reality on some
boxes, some of the time.

All of the Python library's internal socket code does check for the
size actually sent, and loops as needed to complete the task.  Those
idioms then got copied into an endless number of Python applications
too.  So if it's actually the case that send() is a one-gulp operation
across platforms now, we'd never know it!  But better safe than sorry
here.