Single Thread Continuation

[Attila Kelemen]

Rereading what you wrote, I assume you meant that you want to have a
`Cleaner` (which will close the queue), but that is quite an issue, because
then everyone has to provide their own cleaner thread (since there is no
common JDK implementation), and even if there is a common Cleaner that
means a considerable overhead (since now there could be contention for
registering with it) over what the JVM could do for us.

Attila Kelemen <attila.kelemen85 at gmail.com> ezt írta (időpont: 2023. júl.
3., H, 13:55):

> Robert Engels <rengels at ix.netcom.com> ezt írta (időpont: 2023. júl. 3.,
> H, 13:38):
>
>> Believe me. Queues are all you need there is no memory leak and no need
>> to “close”. The producer side uses a weak reference to the queue. When
>> there are no more strong references the producer side can terminate.
>>
>> You can’t use a standard blocking queue for this - but the queue
>> implementation is fairly trivial - with a wake-up thread that listens on
>> the weak reference queue.
>>
>>
>>
> My concern is not that the queue is not getting GCd, but that there will
> be a forever waiting VT. Correct me, if I'm wrong, but I believe you mean
> something like this (btw., the below could be implemented standard Java
> `SynchronousQueue` as well, but I didn't want to bother):
>
> ```
> Iterator<T> toIterator(ForEachable<T> generator) {
>   var queue = ... new SynchronousQueue variant;
>   Thread.startVirtualThread(() -> {
>     try { generator.forEach(e -> queue.put(e)); }
>     finally { queue.finishWriter(); }
>   });
>   return new Iterator<>() { ... obvious implementation based on `queue`
> ... }
> }
> ```
>
> My problem with this is that, if I stop reading the `Iterator` (before
> reading all of its elements), then the started VT will never exit, and that
> looks like a memory leak to me. At least, I can't see how to workaround
> this issue.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230703/55a2be39/attachment-0001.htm>