> "relatively sane" because this isn't really asynchronous
What's your criteria for "really asynchronous"?
> it's just make-believe with a kernel-managed thread pool
To the extent that io_uring uses anything resembling a thread pool, it seems to me that it is used completely differently from how a userspace AIO thread pool operates. When a userspace AIO implementation submits IO to the kernel, it does so with a blocking syscall and that thread stalls until that IO is complete. That means the number of outstanding IOs is limited by the number of threads in the pool. I don't see any such limitation in using io_uring to deliver IO requests to the block layer.
One example might be that related operations, like stat(), opendir(), readdir(), getpeername(), and so on...remain synchronous. And that async functionality is mostly a bolt-on to very established things, file descriptors, berkeley sockets etc.
Also, every improvement is a pretty big patchset with code to ensure the traditional synchronous operations don't get unintended side effects.
Just generally the idea that a "clean start", non-POSIX bound OS might design things differently, I imagine. Google's Fuchsia seems to hit some middle ground, where async is more foundational, for example.
I don't think that observation detracts from the improvements.
> Just generally the idea that a "clean start", non-POSIX bound OS might design things differently, I imagine. Google's Fuchsia seems to hit some middle ground, where async is more foundational, for example.
Microsoft's (research, discontinued) Midori OS was heavily async:
That's exactly where I was going. Critisim of Linux async shouldn't be discouraged because of inherent limitations. That would hample innovation. I wouldn't be surprised by a new web server, API gateway, load balancer, etc, that mandated "forget about POSIX, adhere to this". The whole cloud abstraction movement seems to enable it.
statx exist as opcode, so stat through the ring is a solved problem. Directory operations are not implemented yet, but I'd be surprised if they don't arrive, sooner than later.
> I don't see any such limitation in using io_uring to deliver IO requests to the block layer.
You can already have asynchronous IO from userspace to the block layer via linux-aio and O_DIRECT. But the VFS remains synchronous, so both uring and userspace can effectively only use a thread pool to work around that. Or magic.
What's your criteria for "really asynchronous"?
> it's just make-believe with a kernel-managed thread pool
To the extent that io_uring uses anything resembling a thread pool, it seems to me that it is used completely differently from how a userspace AIO thread pool operates. When a userspace AIO implementation submits IO to the kernel, it does so with a blocking syscall and that thread stalls until that IO is complete. That means the number of outstanding IOs is limited by the number of threads in the pool. I don't see any such limitation in using io_uring to deliver IO requests to the block layer.