6395224: (so) SocketChannel writer blocked on large buffer is not preempted by close method (vista)

[Chris Hegarty]

Alan,

I agree, the solution is not ideal but I think is probably the best we 
can do. I look forward to your changes to separate the blocking and 
non-blocking paths.

I approved this change.

-Chris.

Alan Bateman wrote:
> 
> The test java/nio/channels/AsyncCloseAndInterrupt.java has been failing 
> on Windows for a long time. There are a couple of issues.
> 
> The main one is that we can't asynchronously close a SocketChannel if 
> there is a thread doing I/O on the channel's socket with a buffer size 
> of 128k or more. The issue applies to all versions of Windows from 
> Windows Server 2003 to present day. It can only be solved by limiting 
> the buffer size to less than 128k. Classic networking doesn't run into 
> this because it limits the buffer size to 64k on Windows (that limit 
> stems from a long standing Microsoft recommendation to only use buffers 
> of 64k or smaller).  While this isn't a great solution it should reduce 
> the incidents of WSAENOBUFS that come up periodically with applications 
> doing blocking I/O with huge buffers. I hope some day to separate the 
> blocking and non-blocking paths so this should confine this to blocking 
> I/O.
> 
> The other issues are test related. When testing DatagramChannel it binds 
> to a local address but attempts to connect to the loopback address 
> (different interface). This is corrected by binding to the loopback 
> address. The SocketChannel connect/finishConnect tests need to be able 
> to "saturate" the connection backlog, which just isn't feasible on 
> Window Server editions (no problem on the consumer editions). It's not 
> clear that we can create robust tests for this so for now, these 
> sub-tests are skipped on Windows.
> 
> I've put the webrev here:
>  http://cr.openjdk.java.net/~alanb/6395224/webrev/
> 
> Thanks,
> Alan.
> 
> 
> 
>