On Wed, 26 Mar 2025 20:36:22 GMT, Chris Plummer <cjplum...@openjdk.org> wrote:
>> test/jdk/com/sun/jdi/EarlyThreadGroupChildrenTest.java line 83:
>>
>>> 81: public void classPrepared(ClassPrepareEvent event) {
>>> 82: try {
>>> 83: ++classPreparedCount;
>>
>> It's a long time since I looked at at test based on TestScaffold. Would I be
>> correct to say that it creates an event handler thread to remove events
>> from the event queue and dispatch them to the registered listeners? Only
>> asking as it's not immediately clear if the increment of the event count is
>> correct. I think TestScaffold uses one thread but would need to dig into the
>> test infra to be sure.
>
> Yes, one EventHandler thread dispatching to all listeners. More details below:
>
> There is an interface called TargetListener which declares all the event
> callbacks. TargetAdapter implements TargetListener and provides and empty
> implementation for each callback. TestScaffold extends TargetAdapter, and
> each test extends TestScaffold. So every test has default empty
> implementations of all the callbacks, and can override some (there are a
> couple of overrides in this tests).
>
> A TargetListener instance gets events by adding itself as a listener using
> TestScaffold.addListener(). You can see that this test is doing that early on
> so it gets events.
>
> In addition, some of the TestScaffold APIs will create an instance of a
> TargetAdapter with one or more event callback overrides, and register that
> listener. For example, see waitForRequestedEvent(). So it is possible to have
> 2 or more listeners registered, although as I just pointed out in
> [JDK-8352759](https://bugs.openjdk.org/browse/JDK-8352759), that can be
> problematic at times.
>
> TestScaffold always has an EventHandler thread active (and only one). It sits
> in a loop calling EventQueue.remove(). For any each EventSet received it will
> iterate over each Event in the EventSet, and for each registered listener, it
> will call the listener's event callback for that Event.
BTW, classPreparedCount is somewhat unneeded legacy code. Previously I had
limited it to 50 events to avoid the VMDisconnected exception, but I got rid of
the count check and instead now catch the exception.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24236#discussion_r2014964080
