On Tue, 11 Jul 2023 20:47:41 GMT, Chris Plummer <cjplum...@openjdk.org> wrote:
>> After [JDK-8308232](https://bugs.openjdk.org/browse/JDK-8308232), both the >> test and the debuggee shared the same waittime of 5 minutes. The test would >> wait up to 5 minutes for the expected prompt, but the debuggee would also in >> some cases wait 5 minutes before generating the prompt, which sometimes was >> just a bit too late. Before >> [JDK-8308232](https://bugs.openjdk.org/browse/JDK-8308232), the debuggee >> would wait at most 2 minutes before generating the prompt, so it was always >> generated in time. >> >> The main issue is that after the while loop checks that there are still >> uninterrupted threads remaining, the last of the threads is interrupted >> before the wait() call is made. This means wait() won't return until it >> times out, and by then it is too late, and the test side has already timed >> out waiting for the prompt. >> >> The fix is to widen the synchronized block so the count of not interrupted >> threads remains correct until `wait()` is entered. The other choice was to >> refetch the count after entering the synchronized block, which is what I did >> for the initial fix, but widening seems a better choice so no refetch is >> needed. >> >> For details see >> https://bugs.openjdk.org/browse/JDK-8310551?focusedCommentId=14594838&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14594838 > > Chris Plummer has updated the pull request incrementally with one additional > commit since the last revision: > > Different approach to fix. Widen synchronized block so there is no need to > refetch the notInterrupted count. Looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14817#pullrequestreview-1527151982
