<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>In my example there is no queue. Are you suggesting that all
pre-existing code and all new code should get rewritten using some
new API?</p>
<div class="moz-cite-prefix">On 2026-01-11 18:57, robert engels
wrote:<br>
</div>
<blockquote type="cite" cite="mid:3C66E7C5-ABF7-4247-A88C-08683E7E2075@me.com">
<div dir="ltr">because if park wakes up, the thread already has a
reference to the queue meaning it can start another thread that
puts items into the queue. Meaning the queue is not
“unreferenceable”, so you can’t simply destroy a thread waiting
in park(). </div>
<div dir="ltr"><br>
<blockquote type="cite">On Jan 11, 2026, at 10:30 AM, Viktor
Klang <a class="moz-txt-link-rfc2396E" href="mailto:viktor.klang@oracle.com"><viktor.klang@oracle.com></a> wrote:<br>
<br>
</blockquote>
</div>
<blockquote type="cite">
<div dir="ltr">
<p>>This code is fundamentally broken. Park() can wake up
for any reason. <br>
<br>
I don't see how "When park wakes up" (i.e. the temporal
aspect) affects correctness in any way in the example given.<br>
<br>
>I suggest you look at ClosableQueue - it is correct and
far easier to use. </p>
<p>The example is completely devoid of any queuing concerns.
We're talking about logic which is executed by some thread,
and the person who writes the code does not strictly know
whether that thread is a platform thread, a pooled platform
thread, a virtual thread, an ephemeral virtual thread, a GC
finalizer thread.</p>
<p>In short, this is about: pre-existing code which may get
executed by an ephemeral virtual thread may <i>silently</i>
leak resources under certain circumstances. Now, it can be
argued that most of that code was "not ideal" in the first
place, but the big difference is that when any such defect
gets noticed in a running application, there's a much better
visibility if the thread which ran into the problem is still
there (evidence) vs not (no evidence).</p>
<div class="moz-cite-prefix">On 2026-01-11 01:50, Robert
Engels wrote:<br>
</div>
<blockquote type="cite" cite="mid:1604DAB4-FCCA-4362-BAB9-22237B88AFF4@me.com">
<div dir="ltr">This code is fundamentally broken. Park() can
wake up for any reason. </div>
<div dir="ltr"><br>
</div>
<div dir="ltr">I suggest you look at ClosableQueue - it is
correct and far easier to use. </div>
<div dir="ltr"><br>
<blockquote type="cite">On Jan 10, 2026, at 6:03 PM,
Viktor Klang <a class="moz-txt-link-rfc2396E" href="mailto:viktor.klang@oracle.com" moz-do-not-send="true"><viktor.klang@oracle.com></a>
wrote:<br>
<br>
</blockquote>
</div>
<blockquote type="cite">
<div dir="ltr">
<p>Hi Dmitry,<br>
<br>
An example can look like:<br>
<br>
void method() {<br>
long fileDescriptor = acquireFileDescriptor();<br>
LockSupport.park();<br>
releaseFileDescriptor(fileDescriptor);<br>
}<br>
<br>
If an ephemeral VT executes that method, and there are
no other references to that ephemeral VT, then at the
point of park(), nothing can unpark it anymore, and it
will then never release the file descriptor.<br>
<br>
<br>
><span style="white-space: pre-wrap">We generally don’t allow try blocks (providing other constructs), we also very strongly discourage (just a drop short of disallowing) ANY threading primitives.</span></p>
<p><br>
I don't see how that can work in practice, because it
requires all users of your constructs to be familiar
about exactly how all third-party logic (including JDK
classes) are implemented under the hood. Perhaps I'm
misunderstanding?<br>
<br>
</p>
<div class="moz-cite-prefix">On 2026-01-09 17:27, Dmitry
Zaslavsky wrote:<br>
</div>
<blockquote type="cite" cite="mid:5A5AEC77-43CC-4D2D-87E1-3EC6F8D066AF@gmail.com">
<pre wrap="" class="moz-quote-pre">Not sure what you mean by native resources?
Do you mean what people would use like try resources?
We generally don’t allow try blocks (providing other constructs), we also very strongly discourage (just a drop short of disallowing) ANY threading primitives.
Which makes me think that there is a better way to express my point from before.
I think there is actually a common pattern here.
We use VT inside of the lib. We don’t want users to actually use any threads all.
I think it’s a goal of Alex as well.
We use VT as a way to avoid using threads (if that makes sense).
I think ScopedTasks is going in the same direction. Ideally user just doesn’t know there are threads.
We use Scala (appealing to Victor ;)) vals and immutable collections is the norm.
We don’t want users to think about Threads period.
So the thought of "GC roots on a VT … we don’t want that though to ever occur or we failed ;)
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">On Jan 9, 2026, at 10:26 AM, Viktor Klang <a class="moz-txt-link-rfc2396E" href="mailto:viktor.klang@oracle.com" moz-do-not-send="true"><viktor.klang@oracle.com></a> wrote:
On 2026-01-09 15:39, Dmitry Zaslavsky wrote:
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">someCollection.apar.map { …. }
Can spin N tasks (Each can get it's VT) If some iteration of the loop throws, we don’t need to rest of the code to run, it’s costly.
If the task are not actively mounted but previously started and are waiting… (in our case it’s LockSupport.park) we just want to drop that entire queue and everything around it….
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">How do you handle acquired native resources that are yet to be released?
--
Cheers,
√
Viktor Klang
Software Architect, Java Platform Group
Oracle
</pre>
</blockquote>
</blockquote>
<pre class="moz-signature" cols="72">--
Cheers,
√
Viktor Klang
Software Architect, Java Platform Group
Oracle</pre>
</div>
</blockquote>
</blockquote>
<pre class="moz-signature" cols="72">--
Cheers,
√
Viktor Klang
Software Architect, Java Platform Group
Oracle</pre>
</div>
</blockquote>
</blockquote>
<pre class="moz-signature" cols="72">--
Cheers,
√
Viktor Klang
Software Architect, Java Platform Group
Oracle</pre>
</body>
</html>