[External] : Re: JEP draft: Scope Locals

Mike Rettig mike.rettig at gmail.com
Mon May 17 18:56:32 UTC 2021


On Mon, May 17, 2021 at 1:14 PM Brian Goetz <brian.goetz at oracle.com> wrote:

>
> Let's back up a lot of steps; you're deep in proposing a solution when
>> you've not even explained what problem you think you're solving.  So
>> control question, which I hope will start to expose the assumptions:
>>
>>    Why do you think its important to know that a snapshot of a variable
>> has occurred?
>>
>
> From the JEP:
> "In addition, a Snapshot() operation that captures the current set of
> inheritable scope locals is provided. This allows context information to be
> shared with asynchronous computations."
>
> As the provider of the scoped variable, I'd certainly like to know that my
> scoped variable is being passed into a new scope.
>
>
> Let's try again: why is that important?   What decisions would you make
> differently if you had this information?  What benefit would come from
> those decisions?
>

Threading is hard. Scoped variables are also hard to get right. Combining
the two without an explicit api ignores the complexity that will arise as
scoped variables are passed to other threads. The information is important
so I can choose the appropriate strategy to ensure the thread safety of my
data structure.  With a lifecycle, I can choose whether to create a new
instance or reuse one depending on which I think is more efficient or
safer.  Those decisions are best made at the time a scope is created and
not when a scoped variable is declared. Even *InheritableThreadLocal*
includes the *childValue* method as a hook for child scopes.

Beyond scoped variables, I think properly handling scoping opens new
avenues for traceability and highly concurrent api design.

Mike


More information about the loom-dev mailing list