3 ms·

Your examples are not functionally equivalent. In the first example the callers of both functions are blocked, in the second the callers are not blocked.

• kaba0 4y ago
  That's the point of Java's virtual threads, basically nothing* will block. The JVM can simply replace a blocking user IO call to an async one under the hood, and in the meanwhile schedule another virtual thread to work. When the IO is ready the suspended thread might get continued. * FFI has to be pinned, so it will block
  • Rapzid 4y ago
    In your example the thread is not blocked but the callers are blocked. There is more to async/await than simply keeping os threads unblocked, they also provide a mechanism for keeping callers unblocked and synchronizing async contexts(parallel or concurrent). Is Loom addressing this need? Otherwise it's Goroutines(or any green threading solution) without channels and select. The ecosystem will fracture around solutions to address the boiler and future chaining pains.
    • kaba0 4y ago
      Yes, by the structured concurrency JEP.
    • avodonosov 4y ago
      Java allows not blocking callers using Futures or callbacks for a long time. As well as Promises and callbacks were available in Javascript before async / await. var executor = Executors.newVirtualThreadPerTaskExecutor(); ;; or, for old Java var executor = Executors.newSingleThreadExecutor(); Future<Integer> f = executor.submit(someFunc); What is relevant in the new Java VirtualThreads and Javascript async / await is the possibility to write simple synchronous code, with the performance similar to callback-based asynchronous code.