<div dir="ltr"><div dir="ltr">Am Di., 13. Jan. 2026 um 07:42 Uhr schrieb Alex Otenko <<a href="mailto:oleksandr.otenko@gmail.com">oleksandr.otenko@gmail.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"><div dir="auto">Oh, ok, I confused it with something else. I recall dealing with a system that would panic or report that there were fibers that were no longer going to make progress.<div dir="auto"><br></div><div dir="auto">I think there are plenty of designs with generators, iterators and async where non-termination is not a bug.</div></div></blockquote><div><br></div><div>I have been thinking about this as well, what the difference between various perspectives/designs actually is.</div><div><br></div><div>My first and up to now only idea: a thread comes with hard promises about what things will happen in the future.</div><div><br></div><div>Its accumulated call/handler stack is a batch of unfinished business that is guaranteed to be worked upon.</div><div>If there are two statements "A; B;", then there is a hard promise that normal completion of A implies execution of B.</div><div>If A completes exceptionally, then other rules apply, but they also clearly state what happens next.</div><div><br></div><div>A thread "disappearing" at the point of A would be a mode of completion different from both "normal" and "exceptional".</div><div><br></div><div>-- mva</div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 12 Jan 2026, 11:51 Viktor Klang, <<a href="mailto:viktor.klang@oracle.com" target="_blank">viktor.klang@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>
<p>Yes, just search for "forgotten sender abandoned receiver".</p>
<div>On 2026-01-12 12:22, Robert Engels
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">That is not true. Go routines do not “clean up”
when they cannot make progress due to no producers. Go leaks due
to this are very common. </div>
<div dir="ltr"><br>
<blockquote type="cite">On Jan 12, 2026, at 4:05 AM, Alex Otenko
<a href="mailto:oleksandr.otenko@gmail.com" rel="noreferrer" target="_blank"><oleksandr.otenko@gmail.com></a> wrote:<br>
<br>
</blockquote>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="auto">I'd say it's not even clear why that'd
constitute a bug. Whole systems are built on go-rourines and
continuations getting GCed.
<div dir="auto"><br>
</div>
<div dir="auto">I think there certainly is a clash between
the need to track life cycle of something (tell threads to
terminate) in a system where life cycle of things is not
tracked (because GC).</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, 12 Jan 2026, 09:58
Viktor Klang, <<a href="mailto:viktor.klang@oracle.com" rel="noreferrer" target="_blank">viktor.klang@oracle.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">How
do you find the bug?<br>
<br>
On 2026-01-12 05:36, robert engels wrote:<br>
> Why not just fix your design to ensure the proper
behavior?<br>
<br>
-- <br>
Cheers,<br>
√<br>
<br>
<br>
Viktor Klang<br>
Software Architect, Java Platform Group<br>
Oracle<br>
<br>
</blockquote>
</div>
</div>
</blockquote>
</blockquote>
<pre cols="72">--
Cheers,
√
Viktor Klang
Software Architect, Java Platform Group
Oracle</pre>
</div>
</blockquote></div>
</blockquote></div></div>