JEP draft: Scope Locals

Mike Rettig mike.rettig at gmail.com
Sat May 15 15:45:09 UTC 2021


On Sat, May 15, 2021 at 3:29 AM Andrew Haley <aph at redhat.com> wrote:

> 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 for thread locals is one of the many reasons
> > why it should be avoided.
>
> This requirement sounds similar, but I think it's really a different idea.
> Scope locals are only binding data to names and don't attempt to handle
> lifetime issues. Apart from anything else, that would require a more
> heavyweight mechanism than scope locals, which need to be very lightweight
> for some applications.
>

That is why I find the current proposal for scope locals not very
interesting or useful. It is very lightweight, but it doesn't provide a
very compelling argument as a replacement for thread locals.
As the proposal states "It is possible to emulate most of the features of
scope locals with ThreadLocals, albeit at some cost in memory footprint,
runtime security, and performance." That tells me that there really isn't
much new here and scoped locals aren't something that is going to change
how I code.


>
> Over at Loom we've been talking about lifetimes and Ron has some ideas, but
> scope locals are not likely to be that thing.
>

The lifetimes should be solved first while also considering how that can be
leveraged to replace thread locals. Scoping needs to include nested scopes
introduced by threads (platform and virtual) and by task based executions.


More information about the loom-dev mailing list