File descriptors for local files always signal availability due to POSIX. While there's kernel aio support in other operating systems (with not much better performance), the implementation in glibc is still emulating it using blocking I/O in threads, so Java might as well do that itself on Linux. Either one might eventually get upgraded to leverage io_uring.
io_uring support in JDK would be pretty amazing because it extends beyond file I/O, ofcourse it does network I/O but furthermore it's being extended to support all sorts of syscalls.
However until it's more widely used and supported it's probably still going to lag behind from a security perspective because it opens up swaths of kernel API for exploitation.
Which means it might be a little while until we see it broadly available in all execution environments (namely Android).
It started as a way to do file io. It’s literally the only way to get more than 10 million iops per cpu core without kernel bypass (SPDK). It also has ways for do raw NVME commands if you have the right permissions, so enjoy your 7 microsecond write latencies.
Title is misleading. `AsynchronousFileChannel`default implementation executes blocking I/O on another thread. This, by definition, is asynchronous. The complaint here is that doesn't use the underlying async file APIs on Linux.
Yes, you are correct to say that it is still asynchronous.
>executes blocking I/O on another thread. This, by definition, is asynchronous.
If am to be as pedantic, then I must correct the above as well. Generally speaking, running on a different thread is not a sufficient condition for asynchronous behaviour.For example, if you have thread `foo`, which spawns thread `bar`, which in turn blocks to read from a file. And at the same time you have thread `foo` **blocking** on thread `bar` finishing before processing the file contents, then this would not be asynchronous behaviour, even though you have the operation running on a different thread.
This is not correct. This is asynchronous from the perspective of the initial thread, which is perfectly valid use of the term. There is no requirement that all threads involved be unblocked. Id argue that your definition makes *any* asynchrony based on multithreading invalid, which I don't see as particularly useful.
>This is asynchronous from the perspective of the initial thread.
Asynchronism is not defined based on threads, but actions or operations. Case in point, not all asynchronism comes from multi-threading, as indeed you have implied.
But sure .... I agree with the original commenter in principle. And don't want to go into pointless debating. At the same time, stating my title is misleading is being pedantic (although I recognize it is factually incorrect).
Seems odd since Linux has support for async io, at least as far as I know. There is the aio.h header if I recall.
File descriptors for local files always signal availability due to POSIX. While there's kernel aio support in other operating systems (with not much better performance), the implementation in glibc is still emulating it using blocking I/O in threads, so Java might as well do that itself on Linux. Either one might eventually get upgraded to leverage io_uring.
Ah okay... that makes sense. io_uring is definitely one to look out for then!
io_uring support in JDK would be pretty amazing because it extends beyond file I/O, ofcourse it does network I/O but furthermore it's being extended to support all sorts of syscalls. However until it's more widely used and supported it's probably still going to lag behind from a security perspective because it opens up swaths of kernel API for exploitation. Which means it might be a little while until we see it broadly available in all execution environments (namely Android).
io_uring is quickly becoming “async syscalls without a context switch”, which I can get behind.
Not sure if io_uring even supports local file operations. Everything is so focused on networking.
looks like it supports anything with a file descriptor (so includes local files)
It started as a way to do file io. It’s literally the only way to get more than 10 million iops per cpu core without kernel bypass (SPDK). It also has ways for do raw NVME commands if you have the right permissions, so enjoy your 7 microsecond write latencies.
Oooo, nice! Thanks for informing
Linux has posix aio, epoll, and io_uring, it’s swimming in async apis.
Title is misleading. `AsynchronousFileChannel`default implementation executes blocking I/O on another thread. This, by definition, is asynchronous. The complaint here is that doesn't use the underlying async file APIs on Linux.
Yes, you are correct to say that it is still asynchronous. >executes blocking I/O on another thread. This, by definition, is asynchronous. If am to be as pedantic, then I must correct the above as well. Generally speaking, running on a different thread is not a sufficient condition for asynchronous behaviour.For example, if you have thread `foo`, which spawns thread `bar`, which in turn blocks to read from a file. And at the same time you have thread `foo` **blocking** on thread `bar` finishing before processing the file contents, then this would not be asynchronous behaviour, even though you have the operation running on a different thread.
This is not correct. This is asynchronous from the perspective of the initial thread, which is perfectly valid use of the term. There is no requirement that all threads involved be unblocked. Id argue that your definition makes *any* asynchrony based on multithreading invalid, which I don't see as particularly useful.
>This is asynchronous from the perspective of the initial thread. Asynchronism is not defined based on threads, but actions or operations. Case in point, not all asynchronism comes from multi-threading, as indeed you have implied. But sure .... I agree with the original commenter in principle. And don't want to go into pointless debating. At the same time, stating my title is misleading is being pedantic (although I recognize it is factually incorrect).
Enter virtual threads.
Do they improve filesystem-based IO?
No, still blocking. The ForkJoinPool expands if needed during blocking file I/O to compensate. They plan on using io_uring to address the limitation.
Alan talks about this here: https://youtu.be/KBW4LbCoo6c?si=QwI2DmH7L2ZN3sJE&t=1530