3 ms·
io_uring works fundamentally differently from polling loops and closer to Windows' IOCP (which is awesome and better than everything that existed on Linux for m
by immibis 10mo ago
io_uring works fundamentally differently from polling loops and closer to Windows' IOCP (which is awesome and better than everything that existed on Linux for many years). With a polling loop you wait for data to be available in buffers, and then once you get the ready event, you copy it from the kernel's buffer to yours. With IOCP or io_uring, you submit a long-running read or write event directly into your buffer. You get the event after the read or write call, instead of before. Because of this, it's not possible to make it a drop-in replacement for poll/epoll.
- pengaru 10mo agodidn't prevent libuv from adding support for it when available: https://github.com/libuv/libuv/issues/1947 https://github.com/libuv/libuv/issues/1947
- manwe150 10mo agolibuv is more nearly designed for adding IOCP-like support to epoll systems than epoll to IOCP (though it can approximate either direction), so adding io_uring was already straightforward, by design Aside: the wepoll mentioned in this repo is a standalone project extracted libuv, for projects that only desire to support Berkeley sockets and don’t care about other events sources (processes or pipes)
- cryptonector 10mo agoFrom an abstract API perspective it doesn't matter: it's just fire-and-forget where you call a function that will start some I/O and you associate some sort of event completion notice. The details matter only regarding performance.
- immibis 10mo agoFor this to work, your API has to be an async I/O API not an event listening API. It can't be "wait for readable" - it has to be "do a read and wait for it"
- cryptonector 10mo agoNo, it's "launch a read and elsewhere get a completion event". "do a read and wait for it" is synchronous I/O.