I've been diving into Project Loom and its features, and I've come across some statements about how it automatically yields when it encounters blocking operations. Can someone explain what this means exactly? From what I know about asynchronous programming in Rust and Kotlin, it seems like any code can't simply become suspendable. Instead, functions need to be designed with OS non-blocking I/O methods—like epoll, right? So, how does Loom differ from this approach? Does it eliminate the necessity for using OS primitives like epoll in I/O functions and somehow allow for automatic yielding to other tasks, even if the operations are using blocking OS functions?
4 Answers
You could say they're similar to threads, but definitions can vary. There are OS threads and other kinds like green threads or user-level threads that Java’s virtual threads may resemble more. Understanding the nuances can help clarify things a lot better.
Loom operates quite differently than Kotlin coroutines. Essentially, all Java bytecode runs on the Java Virtual Machine (JVM), and a lot of the time, this will lead to calls to native methods, like file I/O, socket I/O, or waiting for locks. Loom modifies how these blocking calls are handled. Instead of blocking the OS thread, when a virtual thread is in use, its state gets stored in the heap, allowing the OS thread to continue working on other tasks. Later, when the operation finishes, a carrier thread can pick up the virtual thread where it left off. It effectively makes using virtual threads feel just like using real threads from a programming perspective, which is a sleek solution to a complex issue.
And while Loom alters the handling of these methods, remember that the underlying implementations largely remain unchanged. Many blocking calls still attempt a non-blocking approach first and manage the virtual threads accordingly.
But it's not entirely true that the virtual thread is unmounted during I/O operations. For example, in file I/O, the carrier thread might actually block, meaning the virtual thread isn't unmounted. The system tries to spawn a spare thread if needed to keep things running.
I think it's worth noting that the JVM does use something like epoll under the hood on Linux. From what I've grasped, the JVM essentially provides a runtime that's somewhat similar to what's provided in Rust with Tokio, so it's not purely magic.
In essence, the neat trick of Loom relies on the fact that much of the blocking functionality has specialized handling for virtual threads. If a blocking call is detected, Loom registers the virtual thread with a polling mechanism instead of executing the blocking syscall outright, allowing for a more responsive system.
Exactly! The distinction between different types of threads is crucial, especially when discussing how they operate within different systems.