JEP draft: Scope Locals

[Peter Levart]

Hi,

So if scopeLocal.get() is called in a thread outside any .run() scope in 
that thread, it will throw exception and scopeLocal.isBound() will 
return false. Unless it was called on an inheritableScopeLocal which 
inherited binding from parent thread.

What if I wanted to create and start a thread that would be "pristine" - 
not have any ScopeLocal value bound? Is this intentionally not allowed 
in order to make sure that inheritable ScopeLocal(s) can't be cleared by 
code that has no access to ScopeLocal instance(s)?

Another question: Suppose there are two inheritable ScopeLocal variables 
with bound values in scope (A and B) when I take a snapshot:

var snapshot = ScopeLocal.snapshot();

now I pass that snapshot to a thread which does the following:

ScopeLocal
     .where(C, "value for C")
     .run(() -> {
         System.out.printf("A:%s B:%s C:%s\n", A.isBound(), B.isBound(), 
C.isBound());
         ScopeLocal.runWithSnapshot​(() -> {
             System.out.printf("A:%s B:%s C:%s\n", A.isBound(), 
B.isBound(), C.isBound());
         }, snapshot);
         System.out.printf("A:%s B:%s C:%s\n", A.isBound(), B.isBound(), 
C.isBound());
     });

What would this code print?

...in other words, does runWithSnapshot replace the whole set of bound 
values or does it merge it with existing set?


Peter

On 5/12/21 4:42 PM, Andrew Haley wrote:
> There's been considerable discussion about scope locals on the loom-dev list,
> and it's now time to open this to a wider audience. This subject is important
> because. although scope locals were motivated by the the needs of Loom, they
> have many potential applications outside that project.
>
> The draft JEP is at
>
> https://bugs.openjdk.java.net/browse/JDK-8263012
>
> I've already received some very helpful suggestions for enhancements to
> the API, and it'll take me a while to work through them all. In particular,
> Paul Sandoz has suggested that I unify the classes Snapshot and Carrier,
> and it will take me some time to understand the consequences of that.
>
> In the meantime, please have a look at the JEP and comment here.
>
>
> For reference, earlier discussions are at
>
> https://mail.openjdk.java.net/pipermail/loom-dev/2021-March/002268.html
> https://mail.openjdk.java.net/pipermail/loom-dev/2021-April/002287.html
> https://mail.openjdk.java.net/pipermail/loom-dev/2021-May/002427.html
>