<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I created a project to demonstrate. It uses finalizers for simplicity but it easily adaptable to weak reference queues. It only needs a single producer virtual thread per generator.<div class=""><br class=""></div><div class="">see <a href="https://github.com/robaho/generators/tree/main" class="">https://github.com/robaho/generators/tree/main</a><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jul 4, 2023, at 7:24 AM, Robert Engels <<a href="mailto:rengels@ix.netcom.com" class="">rengels@ix.netcom.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div dir="ltr" class=""></div><div dir="ltr" class="">You need 3 threads - the producer the consumer and the watcher (the watcher and producer might be able to be combined with async notifications from the weak reference queue) But it is all encapsulated and virtual threads makes this very cheap - as cheap as actual continuations would be. </div><div dir="ltr" class=""><br class=""><blockquote type="cite" class="">On Jul 4, 2023, at 7:19 AM, Alex Otenko <<a href="mailto:oleksandr.otenko@gmail.com" class="">oleksandr.otenko@gmail.com</a>> wrote:<br class=""><br class=""></blockquote></div><blockquote type="cite" class=""><div dir="ltr" class=""><div dir="auto" class="">So it's not really just the queue.<div dir="auto" class=""><br class=""></div><div dir="auto" class="">Plus you need two of them. Otherwise you can't control the timing of when the next value is produced.</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 4 Jul 2023, 13:13 Robert Engels, <<a href="mailto:rengels@ix.netcom.com" class="">rengels@ix.netcom.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class=""><div dir="ltr" class=""></div><div dir="ltr" class="">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. </div><div dir="ltr" class=""><br class=""></div><div dir="ltr" class="">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. </div><div dir="ltr" class=""><br class=""><blockquote type="cite" class="">On Jul 4, 2023, at 7:01 AM, Robert Engels <<a href="mailto:rengels@ix.netcom.com" target="_blank" rel="noreferrer" class="">rengels@ix.netcom.com</a>> wrote:<br class=""><br class=""></blockquote></div><blockquote type="cite" class=""><div dir="ltr" class=""><div dir="ltr" class=""></div><div dir="ltr" class="">That is built into the Iterator interface. </div><div dir="ltr" class=""><br class=""><blockquote type="cite" class="">On Jul 4, 2023, at 4:05 AM, Alex Otenko <<a href="mailto:oleksandr.otenko@gmail.com" target="_blank" rel="noreferrer" class="">oleksandr.otenko@gmail.com</a>> wrote:<br class=""><br class=""></blockquote></div><blockquote type="cite" class=""><div dir="ltr" class=""><div dir="auto" class="">How does the generator tell the consumer that no more values are forthcoming? </div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 3 Jul 2023, 12:38 Robert Engels, <<a href="mailto:rengels@ix.netcom.com" target="_blank" rel="noreferrer" class="">rengels@ix.netcom.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class=""><div dir="ltr" class=""></div><div dir="ltr" class="">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. </div><div dir="ltr" class=""><br class=""></div><div dir="ltr" class="">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. </div><div dir="ltr" class=""><br class=""><blockquote type="cite" class="">On Jul 3, 2023, at 6:19 AM, Attila Kelemen <<a href="mailto:attila.kelemen85@gmail.com" rel="noreferrer noreferrer" target="_blank" class="">attila.kelemen85@gmail.com</a>> wrote:<br class=""><br class=""></blockquote></div><blockquote type="cite" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br class="">
2. We need to synchronize access to mutable state to avoid memory<br class="">
hazards. This is a separate issue from synchronizing access to<br class="">
mutable state to avoid correctness issues. With virtual threads on<br class="">
a single platform thread, this goes away too (because it's always<br class="">
the same thread observing memory operations; no barriers needed).<br class=""><br class=""></blockquote><div class=""><br class=""></div><div class="">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.</div></div></div>
</div></blockquote></div></blockquote></div>
</div></blockquote></div></blockquote></div></blockquote></div>
</div></blockquote></div></div></blockquote></div><br class=""></div></body></html>