<div dir="ltr"><div dir="ltr">Em qua., 19 de jun. de 2024 às 11:45, Marcin Grzejszczak <<a href="mailto:marcin.grzejszczak@gmail.com">marcin.grzejszczak@gmail.com</a>> escreveu:<br></div><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div>Assumption that everyone has to do some migration to use this feature is acceptable, but still if only the scope would be returned by this API, no changes would be required. I think we constantly go in circles with this and I still do not understand why is it such a big problem (I understood the topic of security, but I'm personally not convinced that this is such a big deal; it's similar to a case if someone didn't close a stream or something like that. If they don't they will have problems too)<br></div></div></div></blockquote></div><div><br></div><div>The following is based on my understanding formed by reading this list, reading the JEPs, and also putting some time reading the implementation (for a reason unrelated with this discussion.) I am neither a maintainer of this software nor an authority on this matter. If my tone is inappropriate, I apologize in advance. This disclaimer was written after my "brain dump".</div><div><br></div>Failing to close a ScopedValue scope is nothing like failing to close a FileInputStream.<div>The consequence of failing to close a FileInputStream is a delay in the prompt release of operating system resources that will eventually be released by a finalizer or a Cleaner, a "resource leak" kind of defect.</div><div>The consequence of failing to close a ScopedValue scope is an "undefined behaviour" kind of defect.</div><div>ScopedValues, previously called ExtentLocals, are all about "call scopes", and behave like a parallel "call stack".<br></div><div>ScopedValue scopes do not stack in some abstract philosophical sense, they very concretely stack onto each other, in memory.</div><div>Closing an inner scope before closing the outer scope is like having a "stack" and pulling out the middle element.</div><div>The meaning of ScopedValue.get would become "undefined" in such a case.</div><div>Designed like this, the implementation would be required to *not* assume scopes are entered and left in the correct order, with the inevitable consequences in the set of optimizations allowed.</div><div>Additionally, ScopedLocals would no longer be reference-immutable from the perspective of a "call scope" -- ScopedValue.get would not be idempotent from the perspective of a "call scope" -- with the inevitable consequences on the set of optimizations allowed.</div><div>Neither virtual threads nor scoped locals are "plug and play" replacements for platform threads and thread locals.</div><div>Perhaps the choice of having virtual threads be API-compatible with platform threads is inducing this intuition.</div><div><br></div><div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Pedro Lamarão</div></div></div></div></div>