Single Thread Continuation

[Alex Otenko]

So it's not really just the queue.

Plus you need two of them. Otherwise you can't control the timing of when
the next value is produced.

On Tue, 4 Jul 2023, 13:13 Robert Engels, <rengels at ix.netcom.com> wrote:

> To elaborate - the producer knows when no more values are coming and marks
> the iterator as such. So the next calls to hasNext()/next() fail
> appropriately. That is trivial.
>
> The only “complex” part of the design is that the returned iterator is
> tracked with a weak reference by the producer. So if it goes out of scope
> the producer can be woken from the blocked/waiting state and clean up.
>
> On Jul 4, 2023, at 7:01 AM, Robert Engels <rengels at ix.netcom.com> wrote:
>
> 
> That is built into the Iterator interface.
>
> On Jul 4, 2023, at 4:05 AM, Alex Otenko <oleksandr.otenko at gmail.com>
> wrote:
>
> 
> How does the generator tell the consumer that no more values are
> forthcoming?
>
> On Mon, 3 Jul 2023, 12:38 Robert Engels, <rengels at ix.netcom.com> wrote:
>
>> 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.
>>
>> On Jul 3, 2023, at 6:19 AM, Attila Kelemen <attila.kelemen85 at gmail.com>
>> wrote:
>>
>> 
>>
>>>
>>> 2. We need to synchronize access to mutable state to avoid memory
>>>    hazards. This is a separate issue from synchronizing access to
>>>    mutable state to avoid correctness issues. With virtual threads on
>>>    a single platform thread, this goes away too (because it's always
>>>    the same thread observing memory operations; no barriers needed).
>>>
>>>
>> That still seems incorrect to me (in principle, in practice it most
>> likely will end up to be fine, but I just wouldn't rely on it), because the
>> barrier is needed to prevent instruction reordering by the compiler, and
>> you are not safe from that by using the same platform thread.
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230704/db14490a/attachment.htm>