Ephemeral threads

[Francesco Nigro]

Just FYI in my experience on writing a Netty custom scheduler I had to
implement on top of. JCTools algorithm (mpsc) a closeable queue for the per
carrier run queue.
You can find the code at
https://github.com/franz1981/Netty-VirtualThread-Scheduler/blob/master/core/src/main/java/io/netty/loom/MpscUnboundedStream.java

And it was useful to have a precise semantic to allow VT bound to run on a
specific carrier to make progress (or complete) once racing with their
scheduler if latter is shutdown.

disclaimer: I am one of the JCTools developers

Il dom 11 gen 2026, 12:12 Michal Domagala <outsider404 at gmail.com> ha
scritto:

> Maybe a good idea would be `Thread.ofEphemeral()` ? Effort on JVM side is
> minimal , because each non-tracked VT is ephemeral, everyone who want
> experiment with ephemeral has an option, no one will comply about
> semaphores, summoned demons, etc. because who consents cannot be injured
>
> sob., 10 sty 2026 o 18:18 Alan Bateman <alan.bateman at oracle.com>
> napisał(a):
>
>> On 10/01/2026 16:00, Andrew Haley wrote:
>> >
>> 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260111/85a327f0/attachment.htm>