[External] : Re: Ephemeral threads

[Viktor Klang]

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?

On 2026-01-11 18:57, robert engels wrote:
> 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().
>
>> On Jan 11, 2026, at 10:30 AM, Viktor Klang <viktor.klang at oracle.com> 
>> wrote:
>>
>> 
>>
>> >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 <viktor.klang at oracle.com> 
>>>> 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<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
>>>>>>
>>>> -- 
>>>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260112/d1799845/attachment.htm>