Ephemeral threads

[Alan Bateman]

On 10/01/2026 16:00, Andrew Haley wrote:
>
> OK, I think I get it. The issue here is that a thread is unreachable 
> but can be resurrected if it's finalized.
>
> So, at some risk of flogging a dead horse, I'm wondering: what if we 
> could figure out a way in which an unreachable thread could be GC'd, 
> but only if it was honest-to-goodness unreachable, i.e. it wasn't on a 
> reference queue and it had no finalizer. We'd be good, right?
>
Hopefully finalization will be disabled by default, and eventually 
removed, but there a lot more to the topic. You can summon other demons 
when the threads act on objects with cleaners (or more generally, 
anything with cleanup actions based on phantom refs). This can lead to 
cleaning actions that attempt to release resources in an inconsistent 
state. Even if we spent a few years on the issues, the usage (to allow 
the alive threads be GC'ed) is very fragile to setup, and the resulting 
behavior would surely be surprising to most developers. If we do 
channels that integrate with structured concurrency then it might be 
that some of the calls for ephemeral threads go away.

-Alan.