On Mon, 26 Sep 2022 15:35:28 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.
test/jdk/java/net/vthread/BlockingSocketOps.java line 714:
> 712: }
> 713:
> 714: static void readToEOF(InputStream in) throws IOException {
just curious: isn't that just `in.readAllBytes()`?
Oh - I see. You don't want to accumulate all the bytes.
An alternative would be `in.transferTo(OutputStream.nullOutputStream())`
-------------
PR: https://git.openjdk.org/jdk/pull/10427
