4 ms·

How does Project Loom in JDK 21 change this? It seems that Java has expended a lot of effort in implementing low cost virtual threads including all the effort n

How does Project Loom in JDK 21 change this? It seems that Java has expended a lot of effort in implementing low cost virtual threads including all the effort needed to make async truly async throughout the Java runtime library.

papercrane 3y ago
The article is about the AsynchronousFileChannel class, which I don't think Project Loom affected at all. Regardless of any future updates, this class will probably always use a thread pool/ExecutorService. It is part of the documented behaviour and API.
cogman10 3y ago
AFIAK, loom hasn't addressed this problem. File IO isn't something I think the majority of devs are dealing with. That said, it's on their wiki as something they plan to address. Virtual threads aren't the end of the dev work here.
twic 3y ago
Loom goes in the opposite direction: it presents a programming model where everything is blocking all the time, then makes threads lightweight, so that's scalable. It doesn't do anything to make file operations truly async; it makes it unnecessary for them to be async.
- jayd16 3y ago
  > it unnecessary for them to be async. Is this true? Wouldn't they still consume an OS thread in that case; possibly consuming the pool of OS threads that are servicing the virtual threads? How does loom handle that?
  - adra 3y ago
    The JVM with virtual threads will do userspace task scheduling to take jobs on and off active OS threads. As long as Java knows he e to safely suspend the running up action, like socket.read(), the JVM could use a read selector on an off thread and something like epoll() to resume the socket and it's calling task when the blocking call is available and an OS thread capable of resuming it.
- gpderetta 3y ago
  Of course, while the user code side would look sync, the loom event scheduler would still need to implement the async file Io support.
jtasdlfj234 3y ago
Virtual Threads, under the hood, cooperatively yield at IO boundaries (on supported APIs)
jakjak123 3y ago
Its not really related at all. Loom allows java thread to in certain cases block, but then yield to run a different thread's code. That principle is unrelated to File IO.

papercrane 3y ago

The article is about the AsynchronousFileChannel class, which I don't think Project Loom affected at all. Regardless of any future updates, this class will probably always use a thread pool/ExecutorService. It is part of the documented behaviour and API.

cogman10 3y ago

AFIAK, loom hasn't addressed this problem. File IO isn't something I think the majority of devs are dealing with. That said, it's on their wiki as something they plan to address. Virtual threads aren't the end of the dev work here.

twic 3y ago

Loom goes in the opposite direction: it presents a programming model where everything is blocking all the time, then makes threads lightweight, so that's scalable. It doesn't do anything to make file operations truly async; it makes it unnecessary for them to be async.

jayd16 3y ago
> it unnecessary for them to be async. Is this true? Wouldn't they still consume an OS thread in that case; possibly consuming the pool of OS threads that are servicing the virtual threads? How does loom handle that?
- adra 3y ago
  The JVM with virtual threads will do userspace task scheduling to take jobs on and off active OS threads. As long as Java knows he e to safely suspend the running up action, like socket.read(), the JVM could use a read selector on an off thread and something like epoll() to resume the socket and it's calling task when the blocking call is available and an OS thread capable of resuming it.
gpderetta 3y ago
Of course, while the user code side would look sync, the loom event scheduler would still need to implement the async file Io support.

jtasdlfj234 3y ago

Virtual Threads, under the hood, cooperatively yield at IO boundaries (on supported APIs)

jakjak123 3y ago

Its not really related at all. Loom allows java thread to in certain cases block, but then yield to run a different thread's code. That principle is unrelated to File IO.