Single Thread Continuation

Attila Kelemen attila.kelemen85 at gmail.com
Mon Jul 3 13:09:51 UTC 2023


I see, so you would start two VTs. One waiting on the `ReferenceQueue` (and
immediately stopping the queue), and another doing the loop. Though I admit
that would be correct, but still would be rather inefficient compared to
what the JVM could do. Also, it wouldn't necessarily be exactly the same,
because for that to work, when you are stopping the queue, you still have
to exit with an exception (from the loop), while the JVM can just finish
executing the thread. Though I guess one could argue that even in a JVM
supported implementation you might want this termination by exception,
otherwise there would be an additional possibility of a finally block never
executing (which is rather dangerous). That said, if we are relying on the
GC to effectively trigger this exception, then that is already an issue,
because the GC does not promise that it will clean up everything.

Robert Engels <rengels at ix.netcom.com> ezt írta (időpont: 2023. júl. 3., H,
14:42):

> The code is not correct. Read about reference queues and weak references
> and how you could have the producer detect when there are no more possible
> readers and clean itself up. You don’t need to provide a cleaner - it can
> all be done internal to the “generator” implementation.
>
> It is not trivial code but it is straightforward.
>
> I’ll give you a clue - you need to have a watcher of the weak references
> that wakes the blocked producer
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230703/61d64acd/attachment-0001.htm>


More information about the loom-dev mailing list