Dropped task -- feature or bug?

[Ron Pressler]

Even if the thread wasn’t gc’ed, you wouldn’t have been able to debug that thread, as virtual threads are not tracked by default. If you want a virtual thread to be tracked for debugging/monitoring purposes, it needs to be started in some “container”, such as the ExecutorService returned from Executors.newVirtualThreadPerTask(). In that case, it will also not be gc-ed.

— Ron

> On 16 May 2022, at 18:29, Brian S O'Neill <bronee at gmail.com> wrote:
> 
> I created a simple test which causes a virtual thread to block forever on a semaphore which never gets released. When the semaphore is gc'd, the virtual task is also gc'd. If the virtual thread is waiting on the semaphore with a timeout, then the task isn't gc'd until after it times out and finishes normally.
> 
> This behavior makes sense considering that the virtual thread would never wake up if waiting forever. Keeping the task around would just leak memory, but does this behavior make debugging more difficult?
> 
> Imagine if the task was supposed to acquire the semaphore, do some work, and then close an open file. Whether the task is gc'd or not, this would create an fd leak. But if the task wasn't gc'd, and I observed an fd leak, I could examine a heap dump and try to figure out what's keeping the file open. With the current behavior, I'd be completely stumped.