On 2/2/22 17:48, Alan Bateman wrote:> At a high level it should be okay to
provide a JDK-internal way to await quiescent. You've added it as a public API
which might be okay for the current exploration but I don't think it would be
exposed in its current form. Once the method returns then there is no guarantee
that the number of waiters hasn't changed, but I think you know that
I thought about blocking waiters regardless of References available in the
Queue. This would leave threads in the quiescent state but References would
pile up in the pendingReferenceQueue exposed by the VM. So I stopped on the
method being a synchronization, rather than a blocking point.
I hoped to guarantee all Queues are empty by waiting a sufficient number of
waiters for each Queue, in the order of Queues passing References between each
other (for a single thread). But now even there, I see handling of a Reference
later in the order may make another one pending, filling up a Queue that was
supposed to be empty. For a strong guarantee that all Queues are empty, some
sort of iteration may be required, that will check no Queue had a new reference
since the last check.
I think a public API is needed as users may have the same problem as we do. But
the current code does not support this (we need to allow user code after JDK
Queues are emptied).
Interesting...
Thanks!
Anton
