ScopedValue.runWhere not returning scope

Pedro Lamarão pedro.lamarao at prodist.com.br
Mon Jun 10 22:40:46 UTC 2024


Em seg., 10 de jun. de 2024 às 17:47, Marcin Grzejszczak <
marcin.grzejszczak at gmail.com> escreveu:


> What I'm just trying to say is that the only thing that I think would be
> beneficial in terms of the api changes is that instead of passing the
> lambda that is doing all the safe keeping for the user (because it limits
> what can be done because of the usage of lambda) one would be able to
> literally do the same but not through the lambda but through manual start
> and stop. The rest of the assumptions would remain the same regardless of
> whether one using a lambda or not.
>

This benefit of having ScopedValues "plug and play" into some interceptor
architecture would come at the cost of removing the structural guarantee
that ScopedValues scopes are entered and left correctly.
That guarantee would be degraded to a user requirement, which the platform
would *not* be allowed to assume at the risk of undefined behaviour -- what
happens if a super scope is closed before a sub scope?

-- 
Pedro Lamarão
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20240610/a5dd4870/attachment.htm>


More information about the loom-dev mailing list