RFR: 8340830: Console.readLine() and Console.printf() are mutually blocking [v6]

[Naoto Sato]

On Tue, 3 Feb 2026 19:59:27 GMT, Naoto Sato <naoto at openjdk.org> 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