Scoped variables

[Ryan Schmitt]

My knee-jerk reaction is "yes, yes it is." To me, the main value
proposition of Loom is that we finally get to do structured programming
again, and scoped variables pair better with this idea than fiber-local
variables. Having said that, it's possible that concerns of migration
compatibility (where fiber-based code exists side-by-side with explicitly
event-driven async code) may render this approach unworkable in practice.

On Fri, Jul 19, 2019 at 5:21 AM Ron Pressler <ron.pressler at oracle.com>
wrote:

> We haven’t had much time to spend on this recently, and we certainly have
> no conclusions as of yet,
> but this is sure to become an area of focus once the more basic areas of
> the API have stabilized.
>
> We are, however, very much interested in hearing some thoughts about this.
> In particular, is the idea
> of a binding with a dynamic scope that reverts to the old value when we
> exit the scope a better one
> than the existing un-scoped lifetime of ThreadLocals, whose value persists
> until the next time it is set?
>
> Ron
>
>
> On July 11, 2019 at 6:38:37 PM, Jon Harper (jon.harper87 at gmail.com) wrote:
>
> Hi list,
> I read with much interest the "scoped variable" discussion from
> December 2018:
> https://mail.openjdk.java.net/pipermail/loom-dev/2018-December/thread.html
>
>
> Towards the end of the conversation, the following was stated:
>
> > dean.long at oracle.com ; 12/7/18 1:15 PM
> > Now might be a good time to start a discussion on how we want scoped
> variables to be created and named.
> > Doug Lea dl at cs.oswego.edu ; Sun Dec 9 14:32:07 UTC 2018
> > Or backing up further, how about a discussion of use cases that should
> be covered?
>
> Has this been done and is there a link to a conclusion ?
>
> My favorite use case is implementing what various logging frameworks
> call Diagnostic Contexts in a way that is safe for everyone, whether
> they use threads manually or abstracted behind Executors (or using
> loom's fibers). I think the current agreement is that Diagnostic
> Contexts are too dangerous (currently implemented with threadlocals)
> because they can spill from one context to another when using
> Executors, resulting in false logs. Logs are a prime example where you
> don't want to explicitly pass a context object everywhere but still
> want your logs to display contextual informations (like a request id).
> This is especially true when you want to add a new log somewhere in
> the code where the context is not passed and you have to backtrack all
> the call chain and add the context object to all the intermediate
> method arguments.
>
> Cheers,
> Jon
>