Need reviewer for 6913877: (fs) AsynchronousFileChannel.write can return wrong result under load [win]

[Christopher Hegarty -Sun Microsystems Ireland]

Alan,

This change looks good. I have just one question about the requirement 
to call Invoker.invoke(result) at the end of the run method of 
WriteTask. I can see that in the ReadTask case this may be an 
optimization for EOF, but I don't think it is necessary for write. If 
you run with system assertions enabled and write throws an Exception 
then the assertion in Invoker.invoke will be triggered, right?

Otherwise looks good.

-Chris.

Alan Bateman wrote:
> 
> This one is a Windows specific reliability issue with 
> AsynchronousFileChannel.write. It's the issue that Joel Buckley brought 
> up on nio-discuss a few days ago. Under load conditions (duplicates for 
> me intermittently on a 8-core server) it is possible for 
> AsynchronousFileChannel.write (or read) to complete with the incorrect 
> result. The issue is similar to 6834246 in that the implementation is 
> using the number of bytes transferred, as returned by 
> WriteFile/ReadFile, as the result. This result is only reliable for 
> synchronous operations so this patch changes the implementation so that 
> result is always handled via the completion notification. The webrev is 
> here:
>  http://cr.openjdk.java.net/~alanb/6913877/webrev.00/
> 
> Thanks,
> Alan.