Re:Async file IO in Java is not truly async [Resource, Tech ...
by riku_iki on Monday January 08, 2024 @05:15PM
(#38919018)
I am not an expert, but my reading is that epoll operates on file descriptors.
[ Parent
| on HN ]
Re:Async file IO in Java is not truly async [Resource, Tech ...
by gpderetta on Monday January 08, 2024 @06:08PM
(#38919741)
Readiness notification, like epoll, is not really suitable for file backed IO. A file on disk is not a FIFO that you can wait for data to be available; what would even mean for notification to be ready to read for a file fd? Consider that reads can be at any offset.
You need completion notifications instead (like IOCP or io_uring or POSIX aio). You could in principle start an async splice from an FD into a pipe and then poll for the pipe to be ready to read, but IIRC there is no async splice.
Re:Async file IO in Java is not truly async [Resource, Tech ...
by jen20 on Monday January 08, 2024 @05:43PM
(#38919405)
This is highly dependent on the filesystem - as far as I know, basically only XFS works, and only for a small subset of operations, and everything else just blocks.
Tokio's filesystem handling in Rust is the same way by default - a pool of IO threads.
Edit: I just remembered that Avi Kivity (of KVM and ScyllaDB fame) wrote a tool to detect this: https://github.com/avikivity/fsqual