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
<[email protected]> wrote:
Am Di., 13. Jan. 2026 um 12:06 Uhr schrieb Andrew Haley <[email protected]>:
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
