[External] : Re: Ephemeral threads

[Dmitry Zaslavsky]

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 <viktor.klang at oracle.com> 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
>