<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
We need the ability to revoke access.<br>
<br>
Consider this scenario. You have a resource that is entirely<br>
unsychronized, so must be accessed by only one thread at a time. A<br>
thread-locked scoped value (called CAP) is used as a capability to<br>
access the region. CAP is a handle which contains a reference to<br>
the owning thread and a reference to the memory region.<br>
<br>
Thread B needs access, so it requests CAP from the current owner,<br>
Thread A. Thread A creates a new capability locked to Thread B, hands<br>
it over, then continues executing, with its own CAP bound either<br>
to null or to the new capability.<br>
<br>
If some code now running in A had stashed a previous set of scoped<br>
value bindings and could restore them, two threads A and B could now<br>
appear to own the same memory region.<br><br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>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).</div><div> </div></div></div>