io_uring is Linux specific. BSD offers kqueue instead, introduced in 2000.
I believe both are limited to specific operations, mostly IO, and aren't fully general asynchronous syscall interfaces.
I believe both are limited to specific operations, mostly IO, and aren't fully general asynchronous syscall interfaces.
I went through the list of operations supported by `io_uring_enter`. Almost all of them are for IO, the remainder (NOP, timeout, madvise) are useful for supporting IO, though madvise might have some non-IO uses as well. While io_uring could form the basis of a generic async syscall interface in the future, in its current state it most certainly is not.
The article mostly talks about io_uring enabling completion based IO instead of readiness based IO.
AFAIK kqueue also supports completion based IO using aio_read/aio_write together with sigevent.
If you can point to a practical example of a program doing it this way and seeing a performance benefit, I would be curious to see it. I did some googling and didn't really even find any articles mentioning this as possibility.
kqueue is widely considered to be readiness based, just like epoll, not completion based.
What you wrote sounds like an interesting hack, but I'm not sure it counts for much if it is impractical to use.
Now nginx could use threads for file io, and linux file performance became ok as well.
As for your "performance benefit" question and nobody using it over readiness based approaches: Well yes. No idea how it compares with a traditional readiness based socket program. But it's kind of not the point either. AFAIK the scenario where POSIX AIO makes most sense is files on disk.
But as has been pointed out elsewhere, io_uring is also about making other syscalls asynchronous.