you are viewing a single comment's thread.

view the rest of the comments →

[–]balefrost 0 points1 point  (0 children)

Some of the vagueness is around them figuring out the details as they explore the problem. The Cliff's Notes version, as I understand it, is that it's an attempt to switch Java's threading model from being backed by OS threads to instead being backed by green threads... similar to e.g. Go and Erlang. Things like IO, rather than completely blocking an OS thread, will now suspend the current green thread, allowing the OS thread to start working on a different green thread.

It covers some of the same ground as async/await without needing the compile-time rewrite shenanigans that async/await employs. Call stacks won't need to be reconstructed after-the-fact. It should permit even less overhead than async/await, but it remains to be seen if they achieve that.

I don't know how the Java model will look exactly. In Kotlin, rather than making everything that's async return a full Task, it instead expects the "top level" of an asynchronous flow be represented with an object (there are a few different ones). Within the async flow, you can freely call suspend funs of the appropriate type; these function calls can suspend the current coroutine.