ScopedValue.runWhere not returning scope

[Marcin Grzejszczak]

Thank you for this great discussion!

> If you consider an execution of a program as a downwards-growing stack, a
scoped value is bound to some value at one point in the stack, and the
bound value is visible to all frames below that point. That is all: there's
no need to consider scopes opening and closing.

In theory that's true. But if we take into consideration frameworks like
Brave [1], Micrometer [2], OpenTelemetry [3] , Apache Camel [4], Apache
Skywalking [5] etc. (so those that work with distributed tracing) that
theoretical viewpoint does not hold. It would be a gigantic shame if they
would need to always rely on ThreadLocals instead of being able to use the
ScopedValues mechanism.

> It's true that this decision makes scoped values less versatile than
thread-local variables, but on the other hand the hard guarantees it
provides make programs easier to reason about. On balance, we consider the
latter more important than the former.

I completely agree with that however for library instrumentors this
separation is extremely important. Also that would cancel out all libraries
that want to use scoped values and work in an SPI model where users can add
functionalities in an isolated fashion (separate before and after logic).
It would require all of the frameworks that I mentioned to completely
rewrite their internals so that the user's code execution would be wrapped
in a e.g. `ScopedValue.runWhere`.

> We did consider (and even implement) an API with open() and close()
methods, but we discarded it in order to make the use you describe
impossible

I understand that with great power comes great responsibility and you want
to guard users from cases like "opening and not closing". I fully
understand that because I've been working in the domain of distributed
tracing for a decade now and I've seen that particular scenario happen
every now and then. It's not a common situation though. Since you've
already implemented it once then you did see reasons for doing that. Is
there a chance to come back to that discussion? What would need to happen
to reopen that conversation once again?

[1]
https://github.com/openzipkin/brave/blob/6.0.3/brave/src/main/java/brave/Tracer.java#L576-L594
[2]
https://github.com/micrometer-metrics/micrometer/blob/v1.13.0/micrometer-observation/src/main/java/io/micrometer/observation/Observation.java#L838-L904
[3]
https://github.com/open-telemetry/opentelemetry-java/blob/v1.38.0/context/src/main/java/io/opentelemetry/context/Context.java#L200-L203
[4]
https://github.com/apache/camel/blob/camel-4.6.0/components/camel-tracing/src/main/java/org/apache/camel/tracing/ActiveSpanManager.java#L136-L144
[5]
https://skywalking.apache.org/docs/skywalking-java/next/en/setup/service-agent/java-agent/application-toolkit-tracer/
(AFAIR upon creation Span is made current and needs to be then closed)

Pozdrawiam / Best regards,
Marcin Grzejszczak

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


czw., 6 cze 2024 o 10:48 Andrew Haley <aph-open at littlepinkcloud.com>
napisał(a):

> On 6/5/24 22:31, Marcin Grzejszczak wrote:
>
>  > I am wondering what if I don't want to use a ThreadLocal but
>  > ScopeValue? Is it the tool to solve this problem? Current API allows
>  > me to run a lambda within a scope through
>  > `ScopedValue.runWhere(scopedValue, "foo", () -> {})`. But what if I
>  > wanted to separate this into 2 steps, the scope opening and closing?
>
> The structured nature of a scoped value is a part of its essential
> design. It is the main difference between scoped values and
> thread-local variables.
>
> If you consider an execution of a program as a downwards-growing
> stack, a scoped value is bound to some value at one point in the
> stack, and the bound value is visible to all frames below that point.
> That is all: there's no need to consider scopes opening and closing.
>
> It's true that this decision makes scoped values less versatile than
> thread-local variables, but on the other hand the hard guarantees it
> provides make programs easier to reason about. On balance, we consider
> the latter more important than the former.
>
> We did consider (and even implement) an API with open() and close()
> methods, but we discarded it in order to make the use you describe
> impossible.
>
> --
> Andrew Haley  (he/him)
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> https://keybase.io/andrewhaley
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>
>
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Nie
zawiera wirusów.www.avg.com
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20240606/f43cb837/attachment.htm>