>This code is fundamentally broken. Park() can wake up for any reason.
I don't see how "When park wakes up" (i.e. the temporal aspect) affects
correctness in any way in the example given.
>I suggest you look at ClosableQueue - it is correct and far easier to
use.
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.
In short, this is about: pre-existing code which may get executed by an
ephemeral virtual thread may /silently/ 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).
On 2026-01-11 01:50, Robert Engels wrote:
This code is fundamentally broken. Park() can wake up for any reason.
I suggest you look at ClosableQueue - it is correct and far easier to
use.
On Jan 10, 2026, at 6:03 PM, Viktor Klang <[email protected]>
wrote:
Hi Dmitry,
An example can look like:
void method() {
long fileDescriptor = acquireFileDescriptor();
LockSupport.park();
releaseFileDescriptor(fileDescriptor);
}
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.
>We generally don’t allow try blocks (providing other constructs), we
also very strongly discourage (just a drop short of disallowing) ANY
threading primitives.
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?
On 2026-01-09 17:27, Dmitry Zaslavsky wrote:
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 ;)
On Jan 9, 2026, at 10:26 AM, Viktor Klang<[email protected]> wrote:
On 2026-01-09 15:39, Dmitry Zaslavsky wrote:
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….
How do you handle acquired native resources that are yet to be released?
--
Cheers,
√
Viktor Klang
Software Architect, Java Platform Group
Oracle
--
Cheers,
√
Viktor Klang
Software Architect, Java Platform Group
Oracle
--
Cheers,
√
Viktor Klang
Software Architect, Java Platform Group
Oracle
