On Tue, 27 Sep 2022 15:35:34 GMT, Alan Bateman <al...@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. > > 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 test/jdk/java/net/vthread/BlockingSocketOps.java line 722: > 720: /** > 721: * Runs the given task asynchronously after the current virtual > thread has > 722: * parked, or after a max wait time, whichever is first. Does this comment need an update to match the current implementation? From what I can see in the current implementation of `runAfterParkedAsync`, in this PR, it doesn't have a "max wait time" construct before triggering the task. ------------- PR: https://git.openjdk.org/jdk/pull/10427
