JEP draft: Scope Locals

[Alex Otenko]

This is precisely the consequence of having the API with higher order
functions.

If someone were to interact with the side-effects of the invocation of the
function given to such a HOF, it needs a specification of the safe ways to
do so (eg "run returns only after the callee completed"), which can mean
open up the API to enable plugging such interactions (eg pass a piece of
computation to be executed after it's done).

Higher order function signature does not tell how the other function is
invoked, nor even how many times (ok, in this case we know it's implied
that it's once).

Then whether the outer try...finally suffices really depends on the
implementation of the HOF, and adding a guarantee that it will suffice
restricts its implementation. Which may be ok, but needs spelling out.

Alex

On Sat, 15 May 2021, 15:28 Nathan Reynolds, <numeralnathan at gmail.com> wrote:

> It could be called finally, cleanup or whatever word makes sense for
> executing cleanup code on an object bound in a ScopeLocal when the binding
> is being discarded for all threads.  In other words, the finally/cleanup
> code would execute when ScopeLocal is going to drop the last reference to
> the object.  This allows for cleaning up memory maps, sockets and other
> resources shared by all of the threads.  Without this, it would be very
> difficult to determine when to clean up the object.
>
> This opens up another question that I may simply have a lack of
> understanding.  Does the Runnable in ScopeLocal.run(Runnable task) execute
> in a separate thread?  If so, does run() return a CompletableFuture?  Would
> it make sense to have a method such as public class ScopeLocal {public
> CompletableFuture<T> supply(Supplier<T> supplier) {...}}?
>
> On Sat, May 15, 2021 at 6:33 AM Alex Otenko <oleksandr.otenko at gmail.com>
> wrote:
>
>> The answer to that is implementation-specific. (What ScopeLocal does when,
>> what is visible through ScopeLocals)
>>
>> I would say it probably is not different from
>> ScopeLocal.when(...).run(try...finally...), but offers different
>> composability.
>>
>> Alex
>>
>> On Sat, 15 May 2021, 11:35 Andrew Haley, <aph at redhat.com> wrote:
>>
>> > 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://www.redhat.com>
>> > https://keybase.io/andrewhaley
>> > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>> >
>> >
>>
>