On Thu, 21 Jul 2022 15:31:48 GMT, Chris Plummer <cjplum...@openjdk.org> wrote:
> This becomes a problem when the test tries to free a raw monitor on exit. It > first disable events, then it frees the raw monitor that the even handler > synchronizes on. However, it's possible that an event can be in flight when > doing this (an event that was triggered before disabling events, but not > fully delivered yet). So now you have a chicken-and-egg problem because you > need a 2nd raw monitor to synchronize around freeing the 1st raw monitor. So > the end result is you can't always safely cleanup on test exit the way we > currently are. I think we are getting away with it because the set of events > we expect is fixed or predictable. So once the test decides it is done, it > won't get more events, even if they are not disabled. Thus we can free the > raw monitor after disabling events without worry of some spurious event > causing an untimely entry into the event handler. However, I thought there > was one test you fixed where we had this exact problem, and you fixed it by > not freeing the raw monitor on exit. `ThreadStart` and `ThreadDeath` events come to mind, since these are now notoriously unpredictable. I fixed it this way for simplicity. However, it is still possible to correctly sync if necessary. ------------- PR: https://git.openjdk.org/jdk/pull/9168
