Re: [External] : Re: Ephemeral threads

[Robert Engels]

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.  I personally find all of the functional APIs (like streams) a mess unless used in a pure function (no exceptions or errors) context.  This (and structured concurrency tbh) feels like it is morphing into another streams mess rather than a simple solution that solves the 80% case.  On Jan 13, 2026, at 8:27 AM, Viktor Klang <viktor.kl...@oracle.com> wrote:  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. 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)... On 2026-01-13 14:43, Robert Engels wrote: Related, there are no changes needed to Java to implement efficient generators using virtual threads. See https://github.com/robaho/generators On Jan 13, 2026, at 6:35 AM, Michael van Acken <michael.van.ac...@gmail.com> wrote:  Am Di., 13. Jan. 2026 um 12:06 Uhr schrieb Andrew Haley <a...@redhat.com>: On 13/01/2026 07:45, Michael van Acken wrote: [...] > 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. That would be a major change to Java. People tend to assume that threads will make progress "eventually", but there can be no guarantees. Thank you for pointing this out.  It made me aware just how much my thinking is predicated around the idea that a method call does complete in either of two ways.  Of course, even a simple endless loop prevents  completion, nor is there any guarantee that it happens before JVM exit. Non-completion comes to my mind usually in the negative "How do I prevent this piece of code from ending up not completing?" (trying to avoid anticipated future pain), or from trying to find out why something unexpectedly hangs.  In the latter case I am grateful for any support the JVM gives me to narrow the problem down, closing the circle to the observability mechanisms mentioned earlier in this thread. Up to now, a method call not completing is for me either something that should be avoided or is an abnormal program condition.  Actively embracing this in places  other than e.g. a thread's top-level method would require some adjustment on my part. -- mva -- Cheers, √ Viktor Klang Software Architect, Java Platform Group Oracle