<html class="apple-mail-supports-explicit-dark-mode"><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"></div><div dir="ltr">If you’re working with queues, a “closable queue” works well and it’s non intrusive. See the docs. </div><div dir="ltr"><br></div><div dir="ltr"><div style="display: block;" class=""><div style="-webkit-user-select: all; -webkit-user-drag: element; display: inline-block;" class="apple-rich-link" draggable="true" role="link" data-url="https://github.com/robaho/closablequeue"><a style="border-radius:10px;font-family:-apple-system, Helvetica, Arial, sans-serif;display:block;-webkit-user-select:none;width:300px;user-select:none;-webkit-user-modify:read-only;user-modify:read-only;overflow:hidden;text-decoration:none;" class="lp-rich-link" rel="nofollow" href="https://github.com/robaho/closablequeue" dir="ltr" role="button" draggable="false" width="300"><table style="table-layout:fixed;border-collapse:collapse;width:300px;background-color:#E6E6E6;font-family:-apple-system, Helvetica, Arial, sans-serif;" class="lp-rich-link-emailBaseTable" cellpadding="0" cellspacing="0" border="0" width="300"><tbody><tr><td vertical-align="center" align="center"><img style="width:300px;filter:brightness(0.97);height:150px;" width="300" height="150" draggable="false" class="lp-rich-link-mediaImage" alt="closablequeue.png" src="cid:E4DF954B-89DA-446B-952F-900E776675A8"></td></tr><tr><td vertical-align="center"><table bgcolor="#E6E6E6" cellpadding="0" cellspacing="0" width="300" style="table-layout:fixed;font-family:-apple-system, Helvetica, Arial, sans-serif;background-color:rgba(230, 230, 230, 1);-apple-color-filter:initial;" class="lp-rich-link-captionBar"><tbody><tr><td style="padding:8px 0px 8px 0px;" class="lp-rich-link-captionBar-textStackItem"><div style="max-width:100%;margin:0px 16px 0px 16px;overflow:hidden;" class="lp-rich-link-captionBar-textStack"><div style="word-wrap:break-word;font-weight:500;font-size:12px;overflow:hidden;text-overflow:ellipsis;text-align:left;" class="lp-rich-link-captionBar-textStack-topCaption-leading"><a rel="nofollow" href="https://github.com/robaho/closablequeue" style="text-decoration: none" draggable="false"><font color="#000000" style="color: rgba(0, 0, 0, 1);">robaho/closablequeue: a Java FIFO blocking queue with "close" semantics. designed for virtual threads.</font></a></div><div style="word-wrap:break-word;font-weight:400;font-size:11px;overflow:hidden;text-overflow:ellipsis;text-align:left;" class="lp-rich-link-captionBar-textStack-bottomCaption-leading"><a rel="nofollow" href="https://github.com/robaho/closablequeue" style="text-decoration: none" draggable="false"><font color="#A2A2A9" style="color: rgba(60, 60, 67, 0.6);">github.com</font></a></div></div></td></tr></tbody></table></td></tr></tbody></table></a></div></div><br></div><div dir="ltr"><br><blockquote type="cite">On Jan 10, 2026, at 6:52 AM, Michal Domagala <outsider404@gmail.com> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr">Hi,<br><br>I would like to present my case for ephemeral VT.<br>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.<br>When session is closed, I remove blocking queue from global concurrent hash map<br>But I have to<br>- keep reference to VT<br>- interrupt VT on-session-closed<br>It is similar to C++ destructor.<br>If I can rely on GC, I will just remove blocking queue reference and everything will happen automatically.<br><br>Regards,<div>Michal Domagala<br><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">sob., 10 sty 2026 o 13:20 Andrew Haley <<a href="mailto:aph@redhat.com">aph@redhat.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 09/01/2026 13:03, Viktor Klang wrote:<br>
> From my perspective, the big issue with ephemerality of VTs is that it<br>
> easily leads to problems where resources leak with no trace of who<br>
> leaked it—which tends to be rather nightmarish to deal with once they<br>
> pop up in production—"Hey, why is this semaphore unbalanced?!".<br>
<br>
I don't understand what scenario you're talking about.<br>
<br>
How, exactly, would you make a thread unreachable? It can't be on any <br>
reachable queue, so it isn't waiting on a timer or I/O. It can't be <br>
running, because the it's trivially reachable.<br>
<br>
Maybe it's waiting on some kind of semaphore that has become <br>
unreachable. In that case, the thread cannot make any progress. It makes <br>
no difference whether you GC it or not. The native resources it holds <br>
will never be released. Semantically, an unreachable thread is not a <br>
thing: it has no properties.<br>
<br>
Therefore, any thread that is unreachable may be GC'd, surely.<br>
<br>
I guess I may be missing some way that an unreachable thread is <br>
observable? If so, what is it?<br>
<br>
-- <br>
Andrew Haley (he/him)<br>
Java Platform Lead Engineer<br>
<a href="https://keybase.io/andrewhaley" rel="noreferrer" target="_blank">https://keybase.io/andrewhaley</a><br>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671<br>
<br>
</blockquote></div>
</div></blockquote></body></html>