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.

> 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?

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.

Of course, while the user code side would look sync, the loom event scheduler would still need to implement the async file Io support.

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.

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.

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

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.