On Mon, 26 Sep 2022 15:35:28 GMT, Alan Bateman <[email protected]> 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 236: > 234: assertTrue(n > 0); > 235: bb.clear(); > 236: } Same here? Should we add a `fail` if we don't receive a `ClosedByInterruptException`? ------------- PR: https://git.openjdk.org/jdk/pull/10427
