ScopedValue.runWhere not returning scope

[Pedro Lamarão]

Em qua., 19 de jun. de 2024 às 12:34, Marcin Grzejszczak <
marcin.grzejszczak at gmail.com> escreveu:


> 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).
>

Consider this about virtual threads, which the Loom team is frequently seen
explaining.
Typically, a "threads" application sets up a thread pool to intermediate
the distribution of tasks to threads, allowing a seemingly unbounded task
set to run onto a fixed size set of task processors.
If one finds-and-replaces this platform thread pool with a virtual thread
pool, all else remaining exactly the same, expecting the performance to
become better may lead to disappointment.
Virtual threads are not "same but better" threads; they are different
threads, optimal for certain threading architectures, not optimal for
others.
The mantra for virtual threads is "do not pool virtual threads".

Consider this about ScopedValues.
One of the optimizations that the proposed design allows is caching.
Because, from the perspective of a "call scope", the result of
ScopedValue.get is idempotent, the implementation is allowed to cache this
value.
One may even hope that the VM would optimize out getter calls in hot code,
if not this day then some day.

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