io_uring does more than IOCP. It's more like an asynchronous syscall interface that avoids the overhead of directly trapping into the kernel. This avoids some overheads IOCP cannot. I'm rusty on the details but the NT kernel has since introduced an imitation: https://learn.microsoft.com/en-us/windows/win32/api/ioringap...

IOCP is great and was ahead of Linux for decades, but io_uring is also great. It's a different model, not a poor copy.

I think they are a bit different - in the Windows kernel, all IO is asynchronous on the driver level, on Linux, it's not.

io_uring didn't change that, it only got rid of the syscall overhead (which is still present on Windows), so in actuality they are two different technical solutions that affect different levels of the stack.

In practice, Linux I/O is much faster, owing in part to the fact that Windows file I/O requires locking the file, while Linux does not.

io_uring makes synchronous syscalls async simply by offloading them to a pool of kernel threads, just like people have done for decades in userspace.

It's not the async part, it's the not invoking the function part - io_uring replaces syscalls with producer consumer ring buffers.

If that were true then presumably Microsoft wouldn't have ported it to Windows:

https://learn.microsoft.com/en-us/windows/win32/api/ioringap...

Although Windows registered network I/O (RIO) came before io_uring and for all I know might have been an inspiration:

https://learn.microsoft.com/en-us/previous-versions/windows/...

That argument holds no water. IOUring is essential for the performance of some modern POSIX programs.

You can see shims for fork() to stop tanking performance so hard too. IOUring doesnt map at all onto IOCP, at least the windows subtitute for fork has “ZwCreateProcess“ to work from. IOUring had nothing.

IOCP is much nicer from a dev point of view because your program can be signalled when a buffer has data on it but also with the information of how much data, everything else seems to fail at doing this properly.

The CQE for e.g. a successful read(2) operation will have the number of bytes read in the `res` field.