On Tue, 3 Feb 2026 19:59:27 GMT, Naoto Sato <[email protected]> wrote:
>> test/jdk/java/io/Console/ReadWriteBlockingTest.java line 78:
>>
>>> 76: CountDownLatch latch = new CountDownLatch(2);
>>> 77:
>>> 78: Thread.ofVirtual().start(() -> {
>>
>> Based on the way this test is setup with _expect_, I think the previous
>> testing code was actually better at detecting the issue at hand, since it
>> "presumably" had a higher chance to `readLine` first. Given the old
>> implementation, `readLine` would acquire the write lock unnecessarily,
>> preventing `printf` from entering and executing, causing the test to fail
>> since _expect_ would never receive the "printf() invoked" and never be able
>> to provide input to `readLine`.
>>
>> The new test "presumably" has equal chances to either read or write first.
>> However, if the `printf` executes first, I don't see how the test will fail.
>> With the old implementation, even if `printf` acquires the lock at first and
>> `readLine` was blocked from entering, `printf` will eventually finish and
>> release the lock, and provide the expected message to _expect_.
>
> Actually, I think the test is deterministic, even withouth any sleep/latch.
> The reason is that the wait is released with `expect` when it receives
> "printf() invoked" no matter which threads uses the console first. Removed
> the count down latch in the previous commit.
OK, it is not. Will revert to the original, which has higher possibility.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/29493#discussion_r2760780596
