Redux 8184157: (ch) AsynchronousFileChannel hangs with internal error when reading locked file

[Alan Bateman]

On 03/07/2019 23:55, Brian Burkhalter wrote:
> :
>
> After re-reading the code while investigating how to write a 
> reproducer for a similar AsynchronousSocketChannel failure, it does 
> not appear that such a failure is possible. In the case of read or 
> write on such a channel, read0() and write0() can return only one of 
> two non-error condition codes: one for when the operation is pending, 
> and another to indicate that the channel has been shut down. Only in 
> the former cases is pending set to true. So the only possibilities for 
> pending to be false are that the channel is either already shutdown or 
> an error occurred while initiating the operation. In both of these 
> cases the OVERLAPPED pointer is correctly removed from the 
> PendingIoCache instance. Note that pending cannot be true if an 
> exception occurred, so removing the OVERLAPPED pointer only on 
> condition that pending is false is sufficient.
>
I went through webrev.03, where the change to 
WindowsAsynchronousSocketChannelImpl is partial reverted, and I think 
it's looking good except for LockTask.pending as that shouldn't be 
needed now.

I see the test has been cleaned up (thanks), but wondering if L51 to 
close the channel can be removed as it should be closed by way of the 
try-with-resources. Also would be nice to avoid the line break at L45. 
The Files.delete at L55 is probably not needed either.

-Alan


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190721/4d5fbe51/attachment.html>