Am Di., 13. Jan. 2026 um 07:42 Uhr schrieb Alex Otenko < [email protected]>:
> 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. > > I think there are plenty of designs with generators, iterators and async > where non-termination is not a bug. > I have been thinking about this as well, what the difference between various perspectives/designs actually is. My first and up to now only idea: a thread comes with hard promises about what things will happen in the future. Its accumulated call/handler stack is a batch of unfinished business that is guaranteed to be worked upon. If there are two statements "A; B;", then there is a hard promise that normal completion of A implies execution of B. If A completes exceptionally, then other rules apply, but they also clearly state what happens next. A thread "disappearing" at the point of A would be a mode of completion different from both "normal" and "exceptional". -- mva > > On Mon, 12 Jan 2026, 11:51 Viktor Klang, <[email protected]> wrote: > >> Yes, just search for "forgotten sender abandoned receiver". >> On 2026-01-12 12:22, Robert Engels wrote: >> >> 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. >> >> On Jan 12, 2026, at 4:05 AM, Alex Otenko <[email protected]> >> <[email protected]> wrote: >> >> >> 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. >> >> 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). >> >> On Mon, 12 Jan 2026, 09:58 Viktor Klang, <[email protected]> wrote: >> >>> How do you find the bug? >>> >>> On 2026-01-12 05:36, robert engels wrote: >>> > Why not just fix your design to ensure the proper behavior? >>> >>> -- >>> Cheers, >>> √ >>> >>> >>> Viktor Klang >>> Software Architect, Java Platform Group >>> Oracle >>> >>> -- >> Cheers, >> √ >> >> >> Viktor Klang >> Software Architect, Java Platform Group >> Oracle >> >>
