On Tue, 27 Sep 2022 15:35:34 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. > > Alan Bateman has updated the pull request with a new target base due to a > merge or a rebase. The incremental webrev excludes the unrelated changes > brought in by the merge/rebase. The pull request contains three additional > commits since the last revision: > > - Change testSocketWrite1 to use in.transfer, and fix typo in comment > - Merge > - Initial commit > 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. That's a really good improvement on the testing time. I gave this PR a try on my local Mac setup and as you note, each `@run` of the test now completes between 2 to 4 seconds for me. Now that these tests complete fast, do you think we should now remove all the `/timeout=300` from each of the test definitions? ------------- PR: https://git.openjdk.org/jdk/pull/10427
