<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">“Thread leak” is real, but I don’t think the solution is to try add auto-cleanup. It almost always points to a poor or overly complicated design. I wrote a few samples in a branch using the Closable Queue <span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><a href="https://github.com/robaho/closablequeue/blob/sample/src/main/java/robaho/queue/sample" class="">https://github.com/robaho/closablequeue/blob/sample/src/main/java/robaho/queue/sample</a></span><div class=""><div class=""><div class=""><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">with the “original” being one that was relying on the auto-cleanup provided by someone else, and these were to demonstrate what I think is a better, simpler, design.</div></div><div class=""><br class=""></div><div class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">The techniques mimic </span><a href="https://go101.org/article/channel-closing.html" class="">https://go101.org/article/channel-closing.html</a><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""> and the proper use of channels. Go’s concurrency design is specifically to not share data, and is closer to CSP, so the heavy use of channels (closable queues) as communication between threads.</span><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""></div><div class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><br class=""></span></div><div class="">Thread leak (or deadlock in a fixed pool environment) was an issue long before virtual threads. Virtual threads if anything will surface the bad code more quickly - as long as the monitoring tools make the VT leaks obvious. Even if this is implemented, most likely it won’t help, as if they have a leak in this case, they will probably leak the producer/queue reference, so the VT won’t be able to be collected anyway.</div><div class=""><br class=""></div><div class="">I truly believe that freeing the resources as if the thread exited up the stack even though it didn’t is going to cause to a ton of problems - making debugging much harder. Yes, you may not have a resource leak, but you have probably masked the underlying problem, and the code is not correct. At least with a resource leak, it is easy to detect that it is happening and why.</div><div class=""><br class=""></div><div class="">The auto-cleanup might solve this one particular issue but it won’t protect people from writing bad code - if anything this allows them to be less diligent and you are only going to make the problems harder to solve.<br class=""><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On Aug 1, 2024, at 9:39 AM, Ron Pressler <<a href="mailto:ron.pressler@oracle.com" class="">ron.pressler@oracle.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><br class=""><blockquote type="cite" class="">On 1 Aug 2024, at 11:08, robert engels <<a href="mailto:robaho@icloud.com" class="">robaho@icloud.com</a>> wrote:<br class=""><br class="">And actually it is even worse than that , because if you are relying on the differing behavior between virtual threads and platform threads to avoid resource leaks in your application, god help you. <br class=""></blockquote><br class="">I don’t know how you can use virtual threads and *not* rely on their different resource (and especially memory) consumption from platform threads. After all, virtual threads are a feature that allows the creation of many threads, and that is accomplished through different memory management. In other words, you use virtual threads *because* they use memory differently from platform threads (although, as I mentioned in other responses, I think you’re making some incorrect assumptions about how threads, including platform threads retain references, and it is not true that a reference that is logically on the stack is always retained).<br class=""><br class="">“Thread leak” is a real problem in languages that allow creating lots of lightweight threads, such as Go.<br class=""><br class="">— Ron</div></div></blockquote></div><br class=""></div></div></div></div></body></html>