News for hackers. Stuff that matters.
Re:Async file IO in Java is not truly async [Resource, Tech ... by nu11ptr on Monday January 08, 2024 @03:36PM (#38917729)
Clickbait title IMO. Essentially Java presents an abstraction and whether the underlying I/O is truly async or emulated depends on the OS. However, such a design allows them to change the underlying implementation to an OS async API at a later time (example: io_uring on linux). At most, perhaps it would be nice if there was an API to query whether it is truly async or not, but most code is going to want it to "just work" and know their code will take advantage of underlying async I/O, when available.

Post from mailing list from a couple years ago, for example: https://mail.openjdk.org/pipermail/loom-dev/2021-November/00...

Re:Async file IO in Java is not truly async [Resource, Tech ... by javier2 on Monday January 08, 2024 @03:47PM (#38917871)
Yeah, this. It will be async when implemented like async on target platform
Re:Async file IO in Java is not truly async [Resource, Tech ... by xxs on Monday January 08, 2024 @03:48PM (#38917882)
I doubt, as that would break any FileChannel.write(ByteBuffer) that expects the buffer to be consumed (remaining()==0)

I suppose it's possible to create a new set of API or augment the existing ones not to use thread pool, still rather unlikely. Also it'd require a general widely supported async from the OS, incl. Windows

Re:Async file IO in Java is not truly async [Resource, Tech ... by twic on Monday January 08, 2024 @04:24PM (#38918373)
> I doubt, as that would break any FileChannel.write(ByteBuffer) that expects the buffer to be consumed (remaining()==0)

You can't expect that with AsynchronousFileChannel::write at the moment, though, because the buffer is consumed on a background thread. As the docs say [1]:

> Buffers are not safe for use by multiple concurrent threads so care should be taken to not access the buffer until the operation has completed.

And as the article says, on Windows, these writes are "truly" async at the OS level, so portable code already needs to deal with that.

[1] https://docs.oracle.com/en/java/javase/17/docs/api/java.base...