On Tue, 3 Feb 2026 18:55:29 GMT, Justin Lu <[email protected]> wrote: >> Naoto Sato 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 nine additional >> commits since the last revision: >> >> - Reflects Jai's review comments >> - Merge branch 'master' into >> JDK-8340830-Console-readLine-printf-mutually-blocking >> - Added @requires condition >> - added jline test run >> - Merge branch 'master' into >> JDK-8340830-Console-readLine-printf-mutually-blocking >> - Fixed indentation >> - Made ProxyingConsole value-based, used anonymous class for LazyConstant >> - Refine exceptions >> - initial commit > > 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. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29493#discussion_r2760762631
