3 ms·
(author here) I didn't mention tokio's io_uring because, as far as I understand, it is unmaintained. I vaguely recall a conversation in which someone (a contri
by Yoric 11mo ago
(author here)
I didn't mention tokio's io_uring because, as far as I understand, it is unmaintained. I vaguely recall a conversation in which someone (a contributor?) was claiming that it was not possible to implement most of the features of tokio on io_uring due to conflicting models. [source needed], obviously.
I will admit the very existence of glommio or monoio had entirely slipped my mind. I'll probably need to add a few paragraphs about thread-per-core runtimes. Thanks!
- yencabulator 11mo ago> due to conflicting models The big one is this, and this will wreck a lot of pre-io_uring APIs: Historically, you pass in a buffer to read(2). There is one buffer per pending read. (And this is a scalability limitation.) With io_uring, you have a pool of buffers and a read completes by grabbing a buffer from the pool and putting the data there. io_uring highest-performance API is fundamentally at odds with the historical read API that was inherited from POSIX to just about every stdlib.