Hi, I would like to present my case for ephemeral VT. I have a websocket, the websocket has a correlated blocking queue, there is a virtual thread which reads from the queue and writes to the websocket session. When session is closed, I remove blocking queue from global concurrent hash map But I have to - keep reference to VT - interrupt VT on-session-closed It is similar to C++ destructor. If I can rely on GC, I will just remove blocking queue reference and everything will happen automatically.
Regards, Michal Domagala sob., 10 sty 2026 o 13:20 Andrew Haley <[email protected]> napisał(a): > On 09/01/2026 13:03, Viktor Klang wrote: > > From my perspective, the big issue with ephemerality of VTs is that it > > easily leads to problems where resources leak with no trace of who > > leaked it—which tends to be rather nightmarish to deal with once they > > pop up in production—"Hey, why is this semaphore unbalanced?!". > > I don't understand what scenario you're talking about. > > How, exactly, would you make a thread unreachable? It can't be on any > reachable queue, so it isn't waiting on a timer or I/O. It can't be > running, because the it's trivially reachable. > > Maybe it's waiting on some kind of semaphore that has become > unreachable. In that case, the thread cannot make any progress. It makes > no difference whether you GC it or not. The native resources it holds > will never be released. Semantically, an unreachable thread is not a > thing: it has no properties. > > Therefore, any thread that is unreachable may be GC'd, surely. > > I guess I may be missing some way that an unreachable thread is > observable? If so, what is it? > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > >
