ScopedValue: Capturing current bindings

[Attila Kelemen]

>
>
> We need the ability to revoke access.
>
> Consider this scenario. You have a resource that is entirely
> unsychronized, so must be accessed by only one thread at a time. A
> thread-locked scoped value (called CAP) is used as a capability to
> access the region. CAP is a handle which contains a reference to
> the owning thread and a reference to the memory region.
>
> Thread B needs access, so it requests CAP from the current owner,
> Thread A. Thread A creates a new capability locked to Thread B, hands
> it over, then continues executing, with its own CAP bound either
> to null or to the new capability.
>
> If some code now running in A had stashed a previous set of scoped
> value bindings and could restore them, two threads A and B could now
> appear to own the same memory region.
>
>
I see. Though in this scenario, I would consider that the code should have
not exposed the reference via the binding directly, but stored in a field,
and simply removed the field value.

Regardless, I accept this reasoning to be more careful due to the fact that
the thread might be used as an ID, and you might want to avoid some
reentrancy problems.

Anyway, knowing this, I will open a new thread soonish (sorry :)) with a
similar request which does not suffer from this potential issue (and tbh,
would be far more useful).

Thanks. From my side, I consider this request closed (maybe, some years
later, when we know more about how this is used, it can be reconsidered,
even if in a different manner).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230605/f5d988a3/attachment.htm>