[External] : Re: Ephemeral threads

[Michael van Acken]

Am Di., 13. Jan. 2026 um 07:42 Uhr schrieb Alex Otenko <
oleksandr.otenko at gmail.com>:

> 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, <viktor.klang at oracle.com> 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 <oleksandr.otenko at gmail.com>
>> <oleksandr.otenko at gmail.com> 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, <viktor.klang at oracle.com> 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
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260113/3c982e5f/attachment.htm>