Single Thread Continuation

[Cristian Lorenzetto]

SynchronousQueue contains thread locks, , it is not suitable for fibers.
Replace this class with another

Il giorno lun 3 lug 2023 alle ore 13:56 Attila Kelemen <
attila.kelemen85 at gmail.com> ha scritto:

> 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/13a7d9c0/attachment.htm>