3 ms·

Maybe this is an arrogant question, but why adding asyncio to these libraries in general in all OSs is slow? I would think that writing the kernel part would b

Maybe this is an arrogant question, but why adding asyncio to these libraries in general in all OSs is slow? I would think that writing the kernel part would be the hardest, but it's usually the event loop implementations that don't use what the Windows/MacOS/Linux kenels offer.

rwmj 3y ago
We tried to add io_uring support to libnbd (and indeed still hope to do so). There's a bit of an "impedance mismatch" between existing event-driven code and io_uring, not impossible, but also not completely easy to just convert code. Especially when you want to keep the non-io_uring code working (for old Linux, BSD etc). To give an example, libnbd does a lot of send and recv system calls interleaved, for sending requests and receiving replies, with a complicated state machine to keep track of when we would block. It's still not obvious how to convert this to an io_uring style where you have to add the send/recv requests to the submission queue and then separately pick up the responses from the completion queue. It's a particular problem dealing with possible errors and keeping the API the same (if you just call exit when you hit any error, it's a lot easier). If you're writing all new code then io_uring is a great choice.
- xiphias2 3y ago
  I was playing with Tokio / Rust on MacOS and hit an about max 500k requests / second limit where the CPU was mostly doing send / recieve calls, not using MacOS asyncio system calls. I know it's a different library, and asyncio is not as flexible as io_uring, but at least batching send / recv calls from different sockets would be good to be able to do.
woooooo 3y ago
Liburing is pretty recent, and it started with a really limited set of syscalls it supports. Everyone is adopting it pretty quickly, actually.
yxhuvud 3y ago
It is because there in general needs to be pretty big structural changes in the programs to make use of it properly.

rwmj 3y ago

We tried to add io_uring support to libnbd (and indeed still hope to do so). There's a bit of an "impedance mismatch" between existing event-driven code and io_uring, not impossible, but also not completely easy to just convert code. Especially when you want to keep the non-io_uring code working (for old Linux, BSD etc). To give an example, libnbd does a lot of send and recv system calls interleaved, for sending requests and receiving replies, with a complicated state machine to keep track of when we would block. It's still not obvious how to convert this to an io_uring style where you have to add the send/recv requests to the submission queue and then separately pick up the responses from the completion queue. It's a particular problem dealing with possible errors and keeping the API the same (if you just call exit when you hit any error, it's a lot easier). If you're writing all new code then io_uring is a great choice.

xiphias2 3y ago
I was playing with Tokio / Rust on MacOS and hit an about max 500k requests / second limit where the CPU was mostly doing send / recieve calls, not using MacOS asyncio system calls. I know it's a different library, and asyncio is not as flexible as io_uring, but at least batching send / recv calls from different sockets would be good to be able to do.

woooooo 3y ago

Liburing is pretty recent, and it started with a really limited set of syscalls it supports. Everyone is adopting it pretty quickly, actually.

yxhuvud 3y ago

It is because there in general needs to be pretty big structural changes in the programs to make use of it properly.