Your code would be broken in our case, but it’s broken in “plain” java case as well. Meaning park() doesn’t have to return…. Exception could be thrown and release never called….
Resources must be used with try blocks (or some logically similar construct) That’s what we are trying to “manage” by having a library construct. That library construct ensures (optionally) that finally (clean up) called up in any case. The other option I would want to consider is allowing try/finally and throwing an interrupt exception. I haven’t played with this. Ideally JVM support that lets me know if there is a finally block on stack would be nice. But I know it’s too much to ask. > On Jan 10, 2026, at 7:02 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]> >>> <mailto:[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
