[External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads
Pedro Lamarão
pedro.lamarao at prodist.com.br
Wed Jul 31 17:23:08 UTC 2024
In the situation being considered, the finally block will never, ever, run.
What is the meaning of requiring that this effect be ordered before or
after some point in time?
Effects that will never, ever, happen, have no place in time to be ordered
here or there.
The machine cannot fail to properly order an effect that will never, ever,
happen.
Em qua., 31 de jul. de 2024 às 14:16, robert engels <robaho at icloud.com>
escreveu:
> More specifically, it is that ‘a’ cannot be reclaimed and the finally not
> run. This breaks the program ordering guarantees as related to
> retainability.
>
> On Jul 31, 2024, at 11:59 AM, Pedro Lamarão <pedro.lamarao at prodist.com.br>
> wrote:
>
>
> This seems to me a simple contradiction of requirements.
> One cannot require that this program behaves as stated, that this thread
> cannot proceed, and then require that the finally block runs.
> Either the thread can proceed, or it cannot.
> If it cannot, requiring that this thread runs code is nonsensical to me.
> Perhaps one should just revise one's queue design and/or implementation to
> avoid becoming "impossible" instead.
> The fact the queue in question allows for "zombie platform thread" does
> not seem a feature to me.
> "zombie platform threads" is just a resource leak in a system with no
> automatic resource reclamation.
>
>
--
Pedro Lamarão
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20240731/3f1190ce/attachment-0001.htm>
More information about the loom-dev
mailing list