Re: [External] : Re: Ephemeral threads

[Robert Engels]

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