<html class="apple-mail-supports-explicit-dark-mode"><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"></div><div dir="ltr">Agreed - all abnormal thread termination (flow control) is tricky. That’s why I would be against creating another model for generators. I think leveraging existing signaling and clean up mechanisms is the way forward. </div><div dir="ltr"><br></div><div dir="ltr">I personally find all of the functional APIs (like streams) a mess unless used in a pure function (no exceptions or errors) context. </div><div dir="ltr"><br></div><div dir="ltr">This (and structured concurrency tbh) feels like it is morphing into another streams mess rather than a simple solution that solves the 80% case. </div><div dir="ltr"><br><blockquote type="cite">On Jan 13, 2026, at 8:27 AM, Viktor Klang <viktor.klang@oracle.com> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<p>I could see that there could be problems with "forcibly"-closing
such generators if generation is stuck on, let's say a stdin
read() and the user of the generator throws the generator
away—which would leave the generator stuck waiting on the read, or
let it time out, before it is reclaimed.</p>
<p>In such situations what often happens is that you split the
responsibility for detecting and disposing to a third party (a
thread), and now you've re-implemented finalization (or some
variant thereof)...</p>
<div class="moz-cite-prefix">On 2026-01-13 14:43, Robert Engels
wrote:<br>
</div>
<blockquote type="cite" cite="mid:42F7E9DD-9FF1-4003-8C1B-0164E9E3666F@ix.netcom.com">
<div dir="ltr">Related, there are no changes needed to Java to
implement efficient generators using virtual threads. See <a href="https://github.com/robaho/generators" moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/robaho/generators</a></div>
<div dir="ltr"><br>
<blockquote type="cite">On Jan 13, 2026, at 6:35 AM, Michael van
Acken <a class="moz-txt-link-rfc2396E" href="mailto:michael.van.acken@gmail.com"><michael.van.acken@gmail.com></a> wrote:<br>
<br>
</blockquote>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">Am Di., 13. Jan. 2026 um 12:06 Uhr schrieb
Andrew Haley <<a href="mailto:aph@redhat.com" moz-do-not-send="true" class="moz-txt-link-freetext">aph@redhat.com</a>>:</div>
<div class="gmail_quote gmail_quote_container">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On
13/01/2026 07:45, Michael van Acken wrote:<br>
[...]<br>
> I have been thinking about this as well, what the
difference between<br>
> various perspectives/designs actually is.<br>
> <br>
> My first and up to now only idea: a thread comes
with hard promises about<br>
> what things will happen in the future.<br>
> <br>
> Its accumulated call/handler stack is a batch of
unfinished business that<br>
> is guaranteed to be worked upon.<br>
<br>
That would be a major change to Java. People tend to
assume that threads <br>
will make progress "eventually", but there can be no
guarantees.</blockquote>
<div><br>
</div>
<div>Thank you for pointing this out. It made me aware
just how much my</div>
<div>thinking is predicated around the idea that a method
call does complete</div>
<div>in either of two ways. Of course, even a simple
endless loop prevents </div>
<div>completion, nor is there any guarantee that it
happens before JVM exit.</div>
<div><br>
</div>
<div>Non-completion comes to my mind usually in the
negative "How do I prevent</div>
<div>this piece of code from ending up not completing?"
(trying to avoid anticipated</div>
<div>future pain), or from trying to find out why
something unexpectedly hangs. In the</div>
<div>latter case I am grateful for any support the JVM
gives me to narrow the problem</div>
<div>down, closing the circle to the observability
mechanisms mentioned earlier in this</div>
<div>thread.</div>
<div><br>
</div>
<div>Up to now, a method call not completing is for me
either something that should</div>
<div>be avoided or is an abnormal program condition.
Actively embracing this in places </div>
<div>other than e.g. a thread's top-level method would
require some adjustment on my part.</div>
<div><br>
</div>
<div>-- mva</div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote>
</blockquote>
<pre class="moz-signature" cols="72">--
Cheers,
√
Viktor Klang
Software Architect, Java Platform Group
Oracle</pre>
</div></blockquote></body></html>