<div dir="auto">Hey, </div><div dir="auto"><br></div><div dir="auto">Your point about streams not being the same is a valid one. That was an incomparable example.</div><div dir="auto"><br></div><div dir="auto">Regardless, in the tracing world we had this issue of potentially not closing the scopes since day one and the users just learned how to use the api properly. We also have given them api alternatives that take in a lambda so that they don't have to worry about it.</div><div dir="auto"><br></div><div dir="auto">If I'm making the mistake that you can assume the equivalence of the two approaches and instead there should be dedicated support for either of them (like reactive and non reactive programming), I would like to hear that so that we can start planning the whole rewrite of the api (rewrite or adding new api).<br clear="all"><br clear="all"><div dir="auto"><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Pozdrawiam / Best regards,</div><div>Marcin Grzejszczak</div><div><br><div><a href="https://marcin.grzejszczak.pl" target="_blank">https://marcin.grzejszczak.pl</a></div><div><a href="https://toomuchcoding.com" target="_blank">https://toomuchcoding.com</a></div></div></div></div></div></div></div></div><div><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 19 Jun 2024 at 17:19, Pedro Lamarão <<a href="mailto:pedro.lamarao@prodist.com.br">pedro.lamarao@prodist.com.br</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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" target="_blank">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><div dir="ltr"><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>
</blockquote></div></div>