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

[Alan Bateman]

On 27/06/2019 20:01, Brian Burkhalter wrote:
> https://bugs.openjdk.java.net/browse/JDK-8184157
> http://cr.openjdk.java.net/~bpb/8184157/webrev.01/
>
>
I think the analysis is good and the approach to consistently leave the 
release of the OVERLAPPED structure to when the completion event is 
posted is good.

One thing that isn't immediately clear from the changes is whether it 
introduces a memory leak when there is an error initiating the I/O 
operation or where there is an async close at around the time that the 
I/O operation is initiated. I would need to study these cases further to 
see if there are issues.

The Windows implementations of AsynchronousSocketChannel and 
AsynchronousServerSocketChannel also remove and free the OVERLAPPED 
structure then the socket operation completes immediately. Will they 
also need attention?

The test will need cleanup, maybe rename it to LockReadWriteStressTest 
or something that is closer to what it actually does. It can use 
try-with-resources to avoid leaking resources when it fails. I assume 
"f" and "l" will be renamed as they are unusual variables names in this 
context. Also the buffer usages is unusual and I can assume can be 
cleaned up too.

-Alan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190630/1ac93916/attachment.html>