ScopedValue.runWhere not returning scope

[Pedro Lamarão]

Em qua., 19 de jun. de 2024 às 11:45, Marcin Grzejszczak <
marcin.grzejszczak at gmail.com> escreveu:


> Assumption that everyone has to do some migration to use this feature is
> acceptable, but still if only the scope would be returned by this API, no
> changes would be required. I think we constantly go in circles with this
> and I still do not understand why is it such a big problem (I understood
> the topic of security, but I'm personally not convinced that this is such a
> big deal; it's similar to a case if someone didn't close a stream or
> something like that. If they don't they will have problems too)
>

The following is based on my understanding formed by reading this list,
reading the JEPs, and also putting some time reading the implementation
(for a reason unrelated with this discussion.) I am neither a maintainer of
this software nor an authority on this matter. If my tone is inappropriate,
I apologize in advance. This disclaimer was written after my "brain dump".

Failing to close a ScopedValue scope is nothing like failing to close a
FileInputStream.
The consequence of failing to close a FileInputStream is a delay in the
prompt release of operating system resources that will eventually be
released by a finalizer or a Cleaner, a "resource leak" kind of defect.
The consequence of failing to close a ScopedValue scope is an "undefined
behaviour" kind of defect.
ScopedValues, previously called ExtentLocals, are all about "call scopes",
and behave like a parallel "call stack".
ScopedValue scopes do not stack in some abstract philosophical sense, they
very concretely stack onto each other, in memory.
Closing an inner scope before closing the outer scope is like having a
"stack" and pulling out the middle element.
The meaning of ScopedValue.get would become "undefined" in such a case.
Designed like this, the implementation would be required to *not* assume
scopes are entered and left in the correct order, with the inevitable
consequences in the set of optimizations allowed.
Additionally, ScopedLocals would no longer be reference-immutable from the
perspective of a "call scope" -- ScopedValue.get would not be idempotent
from the perspective of a "call scope" -- with the inevitable consequences
on the set of optimizations allowed.
Neither virtual threads nor scoped locals are "plug and play" replacements
for platform threads and thread locals.
Perhaps the choice of having virtual threads be API-compatible with
platform threads is inducing this intuition.

-- 
Pedro Lamarão
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20240619/315c54ab/attachment.htm>