[External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads

[Attila Kelemen]

The assumption is that the thread can provably never continue. That implies
`stop` never being called. So, there is no observable difference.

robert engels <rengels at ix.netcom.com> ezt írta (időpont: 2024. júl. 3.,
Sze, 16:38):

> But won’t that be a breaking api change:
>
> /**
> * Retrieves and removes the head of this queue, waiting if necessary
> * until an element becomes available.
> *
> * @return the head of this queue
> * @throws InterruptedException if interrupted while waiting
> */
> E take() throws InterruptedException;
>
> For example, given this code:
>
> T timedGetElement() throws InterruptedException {
>   Timer t = Timer.start();
>    try {
>       return queue.take();
>    } finally {
>       t.stop();
>    }
> }
>
> With the proposed changes, stop() may never be called - leading to
> potential resource leaks.
>
> Whereas currently the rules ensure stop() will be called unless the
> application hard terminates. This would essentially equating thread “death”
> with a hard application termination from an observability standpoint.
>
> You would have similar issues with any tracing/logging type frameworks.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20240703/277f46e8/attachment-0001.htm>