<div dir="auto">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.<div dir="auto">You can find the code at <a href="https://github.com/franz1981/Netty-VirtualThread-Scheduler/blob/master/core/src/main/java/io/netty/loom/MpscUnboundedStream.java">https://github.com/franz1981/Netty-VirtualThread-Scheduler/blob/master/core/src/main/java/io/netty/loom/MpscUnboundedStream.java</a></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">disclaimer: I am one of the JCTools developers </div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">Il dom 11 gen 2026, 12:12 Michal Domagala <<a href="mailto:outsider404@gmail.com">outsider404@gmail.com</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr">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

</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">sob., 10 sty 2026 o 18:18 Alan Bateman <<a href="mailto:alan.bateman@oracle.com" target="_blank" rel="noreferrer">alan.bateman@oracle.com</a>> napisał(a):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 10/01/2026 16:00, Andrew Haley wrote:<br>
><br>You can summon other demons <br>
when the threads act on objects with cleaners (or more generally, <br>
anything with cleanup actions based on phantom refs). This can lead to <br>
cleaning actions that attempt to release resources in an inconsistent <br>
state. Even if we spent a few years on the issues, the usage (to allow <br>
the alive threads be GC'ed) is very fragile to setup, and the resulting <br>
behavior would surely be surprising to most developers<br>
</blockquote></div></div>
</blockquote></div>