[External] : Re: JEP draft: Scope Locals

[Alex Otenko]

Basically, how can we implement try-with-resource.

There seems to be some sense to expose or explain scope local's lifecycle,
so it is clear who needs to do reference counting (for example) and how,
and what a (thread-)safe way of doing so may be (do we need to assume some
scopes may finish before or after, do we need atomics, can we rely on using
two scope locals and rely on order of their lifecycle ending, do we need
atomics) .


Alex

On Tue, 18 May 2021, 03:48 Mike Rettig, <mike.rettig at gmail.com> wrote:

> On Mon, May 17, 2021 at 2:55 PM Brian Goetz <brian.goetz at oracle.com>
> wrote:
>
> >
> > 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 :)
> >
>
> Sorry if that sounded condescending to anyone. I was stating the difficulty
> of threading as a basis for my decision making. I wasn't implying that the
> various experts on this list don't know about threading.
>
>
> >
> > Scoped variables are also hard to get right. Combining the two without an
> > explicit api ignores the complexity that will arise as scoped variables
> are
> > passed to other threads.
> >
> >
> > OK, now we're getting to the actual question; you obviously have some
> > assumptions about the degree of sharing expected, that might be skipping
> a
> > few steps (and then skipping some more steps by jumping to a solution).
> So
> > to ask again: what patterns of access / sharing are you assuming, what
> > risks are you anticipating, etc?
> >
> >
> I'm assuming values that are shared are not always simple immutable data
> structures. Without life cycles mutable data structures are difficult to
> share without a well defined lifecycle and concurrency approach.  I also
> think there are many potential benefits beyond just sharing variables. For
> example, accumulating request information and setting log4j's NDC would be
> trivial.
>
> https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/NDC.html
>
> Scope locals may be called upon in order to reuse an expensive resource
> like a database connection or output stream.  These resources need to be
> flushed and closed at the end of scope. An ideal solution would pass the
> required data structures directly through the api and to any subtasks.
> However thread locals and scoped variables are used when that isn't
> realistic.  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.
> Unless the code I'm invoking gives me some way to await that scope, then I
> don't know when I can proceed.
>
> Mike
>