The brief read of https://openjdk.org/jeps/425 I did suggested that the major
difference between Virtual Threads and Platform Threads is that Virtual Threads
should not be pooled. So the only changes we would need to make would be to use
a Virtual Thread Executor. However, it probably will simplify the logic a bit
as we now determine how big the pool size should be and now we won’t have to -
every request will just get its own.
Ralph
> On Sep 7, 2022, at 11:40 AM, Matt Sicker wrote:
>
> Java 19 is coming out soon, and that includes a preview version of virtual
> threads and structured concurrency APIs. While I’m not that familiar with the
> Java implementation, I’d imagine it’ll have some similarities with Kotlin
> coroutines and other similar structured concurrency libraries.
>
> I’ve played around with the general concept myself, particularly an
> interesting Python library for the same. I think some sort of structured
> concurrency architecture would be useful for making some async aspects of
> Log4j easier to understand (mostly the areas where we spawn threads for
> things, not for async logging). While the API isn’t stable, we can abstract
> it well enough with multi version jars. What I’m more curious about is how
> we’d interact (if at all) with virtual threads, coroutines, or structured
> concurrency APIs in general. If an app uses structured concurrency
> throughout, it might want the logging system to participate in the same flow
> for clean shutdowns.
>
> Does anyone have any more concrete use cases that might be relevant for us?
> Or does this seem more relevant for networking libraries and frameworks?
>
> —
> Matt Sicker
