ScopedValue.runWhere not returning scope

[Marcin Grzejszczak]

Hey,

Your point about streams not being the same is a valid one. That was an
incomparable example.

Regardless, in the tracing world we had this issue of potentially not
closing the scopes since day one and the users just learned how to use the
api properly. We also have given them api alternatives that take in a
lambda so that they don't have to worry about it.

If I'm making the mistake that you can assume the equivalence of the two
approaches and instead there should be dedicated support for either of them
(like reactive and non reactive programming), I would like to hear that so
that we can start planning the whole rewrite of the api (rewrite or adding
new api).

Pozdrawiam / Best regards,
Marcin Grzejszczak

https://marcin.grzejszczak.pl
https://toomuchcoding.com


On Wed, 19 Jun 2024 at 17:19, Pedro Lamarão <pedro.lamarao at prodist.com.br>
wrote:

> 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/76b30387/attachment.htm>