[adra]

If you think about how you use os threads today, you have two main dispatcher pools, default (cpu), and IO (for IO processing). You can now swap out the discrete IO threads with a virtual thread pool instead. You can get the "infinite" IO (blocking) task benefits of virtual threads like normal java virtual thread pools while still using the same benefits of structured concurrency that coroutines grants.

In reality, this will take a bunch of time to actually show much real results. We've been producing async future driven libraries for a long time, and they're generally pretty good at keeping the computer busy while sending out many concurrent IO requests. The real benefits are when these libraries start to support these virtual threads which should ideally lead to less complexity and some lesser compute overhead (my hopes).

For server tasks, it may simply be reducing the total number of OS threads necessary to do the same tasks, since we won't need to depend on farming out work to work pools, so it may actually make some simpler uses of coroutines unnecessary, if I can simply receive request, process, ask blocking source for info, then respond in one virtual thread, why would I need the extra complexity/cost of coroutines for this naive use case anymore?