On Wed, 10 Jul 2024 21:28:50 GMT, Chris Plummer <cjplum...@openjdk.org> wrote:
>> Thank you for the confirming the reason of the timeout. >> >> To be more clear about my point: >> The test has 3 scenarios (see the test description): >> ThreadReference.resume() resumes the thread suspended with: >> * - with thread2.suspend() <BR> >> * - at a breakpoint <BR> >> * - with VirtualMachine.suspend() <BR> >> >> So for 3rd scenario we should not call vm.resume() (as it converts 3rd >> scenario to 1st scenario). >> The test can be fixed by different ways, to me remove logging between >> breakpoint2 and breakpoint3 is the simplest way. >> Note that breakpoint2 is "runt2(), line 2" and breakpoint3 is "runt1(), line >> 7", there are 2 log statements. We can move breakpoint 3 to "runt2(), line >> 3" (I don't see much sense to have breakpoint 3 so far from breakpoint2 - we >> just need to ensure the thread was resumed ) > > Removing log() statements to fix the problem can be risky because someone > could re-add them in the future. What about my idea of doing a short sleep > before the vm.suspend() to make sure the main thread has advanced to the > pipe.readln(), and won't be doing any more log calls until it gets the next > command from the debugger (which should be "quit"). Adding a `sleep()` between two statements does not scale when the test in question is under different loads or run with different options. All it will do is make a hang more rare (and frustrating to analyze). We do use short sleeps when we are in a while-loop checking on a condition of some sort that indicates that the "thing" for which we are waiting to happen has happened. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20088#discussion_r1673123705
