Scope locals

[Paul Sandoz]

Hi Andrew,

Ok.I held off replying immediately to your initial reply in case you found something. I am curious!

I knew I was missing something subtle :-) 

Having compared in more detail Carrier.run with ScopeLocal.runWithSnapshot I now see the performance implications. Making Carrier behave as if bound or unbound to the current thread scope bindings (i.e. snapshots created or not) is tricky.

Maybe it's not possible to unify and instead it's possible to reframe the relationships?

- What if Carrier were ScopeBinder, where ScopeBinder.bind() returns a ScopeMap.
- ScopeBinder.run(...) behaves as if ScopeBinder.bind().run(…). 
- ScopeMap holds both inheritables and nonInheritables that are internal Snapshot instances, or just the former depending on the use-case.
- ScopeLocal.snapshot() returns a ScopeMap that takes the current thread scope bindings for inheritables.

Thus ScopeMap.run substitutes the current thread scope bindings with its own bindings, and ScopeBinder.run concatenates its bindings to the current thread scope bindings (by virtue of taking the current thread scope bindings, prepending to them, then substituting with the prepended scope bindings).

One could argue that passing an explicitly produced ScopeMap is a higher privileged action than obtaining one by ScopeLocal.snapshot(), since the former may contain inheritables. At first thought that odd, but then the consumer of the explicit handover gets to decide on the subsequent behavior i.e. it has access to all locals but only grants access to other threads for the inheritables (and it's anyway possible to pass instances of Carrier today with similar behavior although restricted to the current bindings).

Paul.

> On May 8, 2021, at 1:58 AM, Andrew Haley <aph at redhat.com> wrote:
> 
> On 5/7/21 5:39 PM, Andrew Haley wrote:
>> And I
>> certainly don't want to make it worse, which treating inheritance and
>> adding bindings the same would do.
> 
> Or maybe not. I have an idea, more later...
> 
> -- 
> 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
>