[External] : Re: JEP draft: Scope Locals

[Alex Otenko]

Not quite the same scale of problem, though. A thread local survives for a
long time, so resource management is a rarely executed thing, with
guarantees of when it is safe to release. (Thread termination, etc)

With ScopeLocal presumably the sheer number of scopes can be forbidding for
some mechanisms, and the absence of lifecycle guarantees calls for
reinvention of the wheel.

Ale

On Wed, 19 May 2021, 10:45 Alan Bateman, <Alan.Bateman at oracle.com> wrote:

> 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 do, and how we might cope with
> > mutability of a scope local's values.
> >
> Also just to add that the closable-resource in the example is being used
> on concurrent threads so it already has to cope with attempted usage
> after close or async close (close while in use). Also once we combine
> this with SC then we can be sure that the child task has completed
> before closing the resource.
>
> -Alan
>