Single Thread Continuation

[Alex Otenko]

It should really be channels, not queues. So that either end can close it.
That can also solve the problem that you raise about generators being stuck
in the scheduler forever.

On Mon, 3 Jul 2023, 10:39 Attila Kelemen, <attila.kelemen85 at gmail.com>
wrote:

> Attila Kelemen <attila.kelemen85 at gmail.com> ezt írta (időpont: 2023. júl.
> 3., H, 10:58):
>
>> Robert Engels <rengels at ix.netcom.com> ezt írta (időpont: 2023. júl. 3.,
>> H, 1:58):
>>
>>> When you have virtual threads there is no need for generators - it is
>>> simply queues. The typical generator is simply implemented as a task that
>>> puts values on a queue with blocking semantics. The rest is syntactic
>>> sugar.
>>>
>>>
>>>
>> Though I never checked every detail on how virtual threads are
>> implemented, but your claim looks to be false to me. Consider that you are
>> implementing a normal `Iterator`, and then you don't read the iterator
>> fully. In that case, your virtual thread will be sitting in the scheduler
>> forever waiting to be unblocked, while this is not the case for reasonably
>> implemented generators.
>>
>
> After actually checking the relevant parts of the implementation, I would
> rephrase what I wrote above. While an unmounted thread in this case is not
> in any queue, your "start a virtual thread" solution could still lead to a
> memory leak. Also, I'm not sure if VT (and its stack) is considered to be a
> GC root or not. At least, it looks like the `delete` would never be called
> in `jvmtiEventController.cpp`. Also, creating an intermediate queue is
> probably less efficient than what the JVM can provide. Regardless, it still
> looks conceptually wrong to start a thread that might be alive forever.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230703/5b1df1df/attachment.htm>