title: When a non-blocking send() only transfers partial data, can we assume it would return EWOULDBLOCK the next call?
body: <p>Two cases are well-documented in the man pages for non-blocking sockets:</p>
  
  <ul>
  <li>If send() returns the same length as the transfer buffer, <em>the entire transfer</em> finished successfully, and the socket may or may not be in a state of returning EAGAIN/EWOULDBLOCK the next call with >0 bytes to transfer.</li>
  <li>If send() returns -1 and errno is EAGAIN/EWOULDBLOCK, <em>none of the transfer</em> finished, and the program needs to wait until the socket is ready for more data (EPOLLOUT in the epoll case).</li>
  </ul>
  
  <p>What's not documented for nonblocking sockets is:</p>
  
  <ul>
  <li>If send() returns a positive value smaller than the buffer size.</li>
  </ul>
  
  <p>Is it safe to assume that the send() would return EAGAIN/EWOULDBLOCK on even one more byte of data? Or should a non-blocking program try to send() one more time to get a conclusive EAGAIN/EWOULDBLOCK? I'm worried about putting an EPOLLOUT watcher on the socket if it's not actually in a "would block" state to respond to it coming out of.</p>
  
  <p>Obviously, the latter strategy (trying again to get something conclusive) has well-defined behavior, but it's more verbose and puts a hit on performance.</p>