RFR: 8296797: java/nio/channels/vthread/BlockingChannelOps.testSocketChannelWriteAsyncClose failed with ClosedChannelException

[Chris Hegarty]

On Fri, 11 Nov 2022 11:37:18 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a test only change. BlockingChannelOps includes 4 tests that exercise async close/interrupt of a virtual thread that is blocked writing to a socket or pipe. The "setup" to have a thread to block indefinitely when writing is complicated when the underlying socket is non-blocking. It's very kernel dependent as to the behavior when the socket send buffer is full and there isn't anything reading from the other end of the connection. On macOS the socket becomes writable again after a 5s timeout, at which point a thread can write more bytes. On Windows the socket becomes writable again after a 1s. This behavior is nothing to do with virtual threads of course, its just the way that some kernels work with sockets configured non-blocking. For the test it means the methods that exercise async close/interrupt of a writer need to deal with the possibility that the writer thread may block more than once. If the writer thread blocks but awakes around the time of the async close/interrupt
  then its next call to write will close the channel and cause ClosedChannelException to be thrown. The 4 tests are changed to handle this so that they retry until they get the more specific exception expected for the scenario. The retry is rare, maybe 1 in 500 runs, and more efficient than changing the test to delay 5+ seconds to be sure that the writer thread is blocked.
> 
> While updating this test I noticed that some of the tests using Pipe don't close both the source and sink. Also the "delay XXX" comment in some tests is a bit misleading, and dates from when the test did use a delay/sleep.

LGTM

-------------

Marked as reviewed by chegar (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11107