[External] : Re: Ephemeral threads

[Michael van Acken]

Am Di., 13. Jan. 2026 um 12:06 Uhr schrieb Andrew Haley <aph at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260113/a2c5a0db/attachment-0001.htm>