RFR [8058099] (ch) Cleanup in FileChannel/FileDispatcher native implementation [win]

[Ivan Gerasimov]

Thank you Alan!

On 22.09.2014 12:03, Alan Bateman wrote:
> On 10/09/2014 11:36, Ivan Gerasimov wrote:
>> Hello!
>>
>> This is a proposal to slightly rework FileChannel/FileDispatcher 
>> native implementation on Windows.
>> If the newer API is used (which is already available on XP and 2003), 
>> this will make code a bit clear and let us save a few redundant calls.
>>
>> Would you please help review the change?
>>
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8058099
>> WEBREV: http://cr.openjdk.java.net/~igerasim/8058099/0/webrev/
> I've finally found time to look at this.
>
> The update to position0 looks good. There isn't a need to init result 
> to 0 but it doesn't matter either way. Same thing in size0.
>
I've tried to make it consistent with other code. Though, we have 
examples of both initially uninitialized variables and variables preset 
to zero.
Hopefully the compiler will produce the same correct code in both cases.

> With the changes to pread0 and pwrite0 then we are using an OVERLAPPED 
> structure to specify the position to ReadFile/WriteFile. Are we 
> guaranteed that these will always execute synchronously and that 
> ERROR_IO_PENDING will not be returned?
>
According to MSDN [1, 2], the last error code ERROR_IO_PENDING may only 
be set if the file was opened with FILE_FLAG_OVERLAPPED. This is not our 
case here.

Here's the quotation from the ReadFile doc page:
"Considerations for working with synchronous file handles:   . . .
If lpOverlapped is not NULL, the read operation starts at the offset 
that is specified in the OVERLAPPED structure and ReadFile does not 
return until the read operation is complete."
And the same holds for WriteFile().

The only non-obvious effect of using the OVERLAPPED structure with a 
synchronous access was testing for EOF.
According to MSDN [3], synchronous read should return TRUE upon reaching 
EOF, setting number of bytes read to zero.

In the real life, when the synchronous read is performed with non-null 
pointer to OVERLAPPED structure, the ReadFile function behaves in the 
same way as for asynchronous access: it returns FALSE and sets the last 
error to ERROR_HANDLE_EOF.

This is why I had to add the code at line 162:
162         if (error != ERROR_HANDLE_EOF) { . . .


[1] 
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365467(v=vs.85).aspx
[2] 
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365747(v=vs.85).aspx
[3] 
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365690(v=vs.85).aspx

Sincerely yours,
Ivan