On Tue, 27 Sep 2022 11:50:16 GMT, Jaikiran Pai <j...@openjdk.org> wrote:
>> BlockingChannelOps.java and BlockingSocketOps.java test virtual threads >> doing blocking I/O on channels and java.net sockets. >> >> BlockingChannelOps has 32 tests at this time and takes nearly 120s to run >> due to several tests that sleep to improve the chances that threads are >> blocked. These sleeps can be replaced with a poll of the thread state so the >> test runs in 3-4s. BlockingSocketOps has be changed to do the same time. >> >> In passing, I updated the tests in BlockingSocketOps that bound a >> ServerSocket to the wildcard address so they bind to the loopback address >> instead. This helps reduce potential interference in CI environments. I also >> put a workaround into BlockingChannelOps for macOS where the kernel appears >> to increase the amount of bytes that can be buffered in the socket sender >> buffer, it's otherwise too hard to test that socket writes block on that >> platform. > > test/jdk/java/nio/channels/vthread/BlockingChannelOps.java line 206: > >> 204: assertTrue(n > 0); >> 205: bb.clear(); >> 206: } > > Hello Alan, since `AsynchronousCloseException` is expected here, should we > add a `fail` after this loop if we don't receive that exception It's an infinite loop as write may need to be called many times before it blocks. So you can't put a `fail` after the loop as it will never be executed. If another exception is thrown then the test will fail. ------------- PR: https://git.openjdk.org/jdk/pull/10427
