7176630: (sc) SocketChannel.write does not write more than 128k when channel configured blocking [win]

[Alan Bateman]

On 14/06/2012 00:28, Esmond Pitt wrote:
> Alan
>
> I suggest the loop should only happen in blocking mode, if at all.
> Non-blocking mode programs must already cope with short writes, and
> shouldn't be held up dispatching writes, on fairness grounds. I'm not
> convinced about the need for the loop in blocking mode either, as
> applications must be written correctly, and forums are already full of war
> stories about checking write (and read) return values in java.nio and indeed
> java.net and java.io.
>
> EJP
>
This patch does not change anything when doing writes with <= 
MAX_BUFFER_SIZE so there isn't any loop in either blocking or 
non-blocking mode (a short write in non-blocking mode is as before, it 
just cause the function to return with the number of bytes written). For 
 > MAX_BUFFER_SIZE case this write(ByteBuffer) currently only writes up 
to MAX_BUFFER_SIZE. The changes means that the blocking write will 
attempt to write all remaining bytes, in the non-blocking case it will 
do the same except that a short write will cause the loop to terminate 
early. At some point I'd like to split the blocking and non-blocking 
code paths in NIO but not in this patch.

As regards people not checking the return value, yes, we see this all 
the time too. The specification sets the expectation that all remaining 
bytes will be written in blocking mode so this is why it is viewed as a 
regression in jdk7. As part of a follow-on patch we will need to adjust 
the specification slightly as there will be cases in non-blocking mode 
where all remaining bytes cannot be written, write(ByteBuffer[]) with an 
array larger than IOV_MAX is one example that comes to mind.

-Alan