On Tue, 27 Sep 2022 13:35:41 GMT, Daniel Fuchs <[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/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())`
Or perhaps `InputStream.skip(MAX_INT)`.
-------------
PR: https://git.openjdk.org/jdk/pull/10427
