Re: JEP draft: Scope Locals

On 5/19/21 10:51 PM, David Lloyd wrote: > I think it would be really nice if the snapshot class could hold its > run/call method rather than making it a static method of `ScopeLocal`. This > reads more naturally to me (and is nicer to write): True, but inheritance is *extremely* time-critical when

Re: JEP draft: Scope Locals

On 5/19/21 9:55 PM, David Lloyd wrote: > Turning this around, I would argue that there are few (or perhaps *no*) > cases where it would ever be desirable to inherit scope locals across > thread creation; in cases where this is explicitly desired, one can always > resume the snapshot from within the

Re: JEP draft: Scope Locals

On 5/19/21 5:55 PM, Peter Levart wrote: > In other words, non-inheritable bindings are > never transferred from thread to thread automatically or by > snapshot/runWithSnapshot. I can see that snapshot/runWithSnapshot was > meant as a mechanism to "simulate" inheritance of bindings when > execut

Re: JEP draft: Scope Locals

On 5/15/21 6:15 PM, Remi Forax wrote: > I think the JEP should be more explicit about the shortcoming of ThreadLocal > and how the design of scope local fix both issues. Yes. It's in progress. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https:/

Re: JEP draft: Scope Locals

On Wed, May 12, 2021 at 9:43 AM 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

Re: JEP draft: Scope Locals

On Wed, May 19, 2021 at 4:01 AM Andrew Haley wrote: > On 5/15/21 6:50 PM, Peter Levart wrote: > > 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 ScopeLoc

Re: JEP draft: Scope Locals

On 15/05/2021 19:50, Peter Levart wrote: 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    

Re: [External] : Re: JEP draft: Scope Locals

On 19/05/2021 10:15, Andrew Haley wrote: : Yes, that's true. I think that what you have in mind is a more elaborate mechanism than what is proposed here, which does no more than bind values to names over a scope. There needs to be more discussion in the JEP of what this proposal isn't intended to

Re: [External] : Re: JEP draft: Scope Locals

On 5/18/21 3:19 AM, Mike Rettig wrote: > With the current proposal I can't simply flush and close at the > end of the scope because there might be a child scope that is still active. Yes, that's true. I think that what you have in mind is a more elaborate mechanism than what is proposed here, whic

Re: JEP draft: Scope Locals

On 5/15/21 6:50 PM, Peter Levart wrote: > 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 Scop

Re: [External] : Re: JEP draft: Scope Locals

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. Gee, thanks MIke for pointing that out to me, obviously I'm new to the topic :) Scoped variables a

Re: [External] : Re: JEP draft: Scope Locals

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

Re: [External] : Re: JEP draft: Scope Locals

How so? How do I know if a snapshot of my variable has occurred? 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 t

Re: JEP draft: Scope Locals

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 th

Re: JEP draft: Scope Locals

; , "loom-dev" > > Envoyé: Mercredi 12 Mai 2021 20:57:33 > Objet: Re: JEP draft: Scope Locals > Scope locals have come together nicely. > > I have some vague thoughts on the presentation of the JEP draft.  There > are (at least) three intertwined things in the mo

Re: JEP draft: Scope Locals

On 5/15/21 10:10 AM, Alex Otenko wrote: > ScopeLocal.where(...).run(...).finally(...) would be nice. Is that different from try ... run ... finally ? -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98

Re: JEP draft: Scope Locals

On 5/14/21 8:19 PM, Mike Rettig wrote: > I don't see a way to capture the lifecycle of the scoped variable. I think > for framework designers it's going to be important to know the life cycle > of the scoped variable especially with snapshotting and inheritance. The > lack of a defined life cycle

Re: JEP draft: Scope Locals

On 5/15/21 12:28 AM, Nathan Reynolds wrote: > What about cleanup of the scoped objects? For example, how do I ensure > close() or some cleanup method is called at the right time on the scoped > object? Do I need to use a Weak/Soft/PhantomReference and a ReferenceQueue > to track the object? Do I

Re: JEP draft: Scope Locals

The lifecycle is bounded by the duration of the Runnable passed to the `run()` method. In the simple case, with no inheritance and no snapshotting:     ScopedLocal.where(x, xExpr).run(r) the lifecycle of the binding starts when we enter r, and ends when we return from r. With snapshotting,

Re: JEP draft: Scope Locals

On 5/14/21 3:45 PM, Brian Goetz wrote: > Where I think the JEP draft (the exposition, not the feature design) > could be improved is to make the relationship to TL more clear.  IMO, > this is a "more modern" TL design; it addresses the same primary use > cases, without the unconstrained mutabili

Re: JEP draft: Scope Locals

Its simpler than you're making it.  Think of the motivating use cases for ThreadLocal, such as when a container calls into user code, and the user code calls back into the container, and we need to keep track of {transaction, security, etc} context, and it is impractical to pass them all throug

Re: JEP draft: Scope Locals

The essence of the example seems to be that the callback is supporting multiple client contexts and when called needs to act relative to the specific client context. The callback does not get a parameter identifying the client context because the library that calls it does not know anything abo

Re: JEP draft: Scope Locals

On 5/13/21 4:59 PM, Alan Snyder wrote: > > >> On May 13, 2021, at 2:03 AM, Andrew Haley wrote: >> >> On 5/12/21 8:12 PM, Alan Snyder wrote: >>> From the motivation section: >>> So you want to invoke a method |X| in a library that later calls back into your code. In your callback you n

Re: JEP draft: Scope Locals

Em qui., 13 de mai. de 2021 às 13:36, Alan Snyder escreveu: > >> Is this a common practice? Doesn’t it point to a deficiency in the > library API? > > > > Not necessarily. For example, say you want to give access to a particular > > resource (a log stream, say) to trusted callees. Nobody AFAIK p

Re: JEP draft: Scope Locals

> On May 13, 2021, at 2:03 AM, Andrew Haley wrote: > > On 5/12/21 8:12 PM, Alan Snyder wrote: >> From the motivation section: >> >>> So you want to invoke a method |X| in a library that later calls back into >>> your code. In your callback you need some context, perhaps a transaction ID >>>

Re: JEP draft: Scope Locals

On 5/12/21 8:12 PM, Alan Snyder wrote: > From the motivation section: > >> So you want to invoke a method |X| in a library that later calls back into >> your code. In your callback you need some context, perhaps a transaction ID >> or some |File| instances. However, |X| provides no way to pass a

Re: JEP draft: Scope Locals

From the motivation section: > So you want to invoke a method X in a library that later calls back into your > code. In your callback you need some context, perhaps a transaction ID or > some File instances. However, X provides no way to pass a reference through > their code into your callback.

Re: JEP draft: Scope Locals

Scope locals have come together nicely. I have some vague thoughts on the presentation of the JEP draft.  There are (at least) three intertwined things in the motivation:  - ThreadLocal (and ITL especially) were always compromises, and with the advent of Loom, have become untenable -- but the

JEP draft: Scope Locals

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