[External] : Re: Ephemeral threads

[Viktor Klang]

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.acken at gmail.com> wrote:
>>
>> 
>> 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
>>
-- 
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/b9530aec/attachment-0001.htm>