3 ms·

Turns out, if you give people a sane API, they actually want to use it! And this is the first relatively sane way on Linux/BSD to do asynchronous IO. :) (I say

Turns out, if you give people a sane API, they actually want to use it! And this is the first relatively sane way on Linux/BSD to do asynchronous IO. :) (I say "relatively sane" because this isn't really asynchronous, it's just make-believe with a kernel-managed thread pool, because I/O being a fully synchronous affair is ingrained far too deep into both Linux and BSD I/O stacks.)

wtallis 7y ago
> "relatively sane" because this isn't really asynchronous What's your criteria for "really asynchronous"? > it's just make-believe with a kernel-managed thread pool To the extent that io_uring uses anything resembling a thread pool, it seems to me that it is used completely differently from how a userspace AIO thread pool operates. When a userspace AIO implementation submits IO to the kernel, it does so with a blocking syscall and that thread stalls until that IO is complete. That means the number of outstanding IOs is limited by the number of threads in the pool. I don't see any such limitation in using io_uring to deliver IO requests to the block layer.
- tyingq 7y ago
  >What's your criteria for "really asynchronous" One example might be that related operations, like stat(), opendir(), readdir(), getpeername(), and so on...remain synchronous. And that async functionality is mostly a bolt-on to very established things, file descriptors, berkeley sockets etc. Also, every improvement is a pretty big patchset with code to ensure the traditional synchronous operations don't get unintended side effects. Just generally the idea that a "clean start", non-POSIX bound OS might design things differently, I imagine. Google's Fuchsia seems to hit some middle ground, where async is more foundational, for example. I don't think that observation detracts from the improvements.
  - chriswarbo 7y ago
    > Just generally the idea that a "clean start", non-POSIX bound OS might design things differently, I imagine. Google's Fuchsia seems to hit some middle ground, where async is more foundational, for example. Microsoft's (research, discontinued) Midori OS was heavily async: http://joeduffyblog.com/2015/11/19/asynchronous-everything http://joeduffyblog.com/2015/11/19/asynchronous-everything
    - tyingq 7y ago
      That's exactly where I was going. Critisim of Linux async shouldn't be discouraged because of inherent limitations. That would hample innovation. I wouldn't be surprised by a new web server, API gateway, load balancer, etc, that mandated "forget about POSIX, adhere to this". The whole cloud abstraction movement seems to enable it.
  - yxhuvud 7y ago
    statx exist as opcode, so stat through the ring is a solved problem. Directory operations are not implemented yet, but I'd be surprised if they don't arrive, sooner than later.
    - tyingq 7y ago
      I view that as confirmation of the GP observation. Async is an afterthought for Xnix.
- blattimwind 7y ago
  > I don't see any such limitation in using io_uring to deliver IO requests to the block layer. You can already have asynchronous IO from userspace to the block layer via linux-aio and O_DIRECT. But the VFS remains synchronous, so both uring and userspace can effectively only use a thread pool to work around that. Or magic.
mzs 7y ago
Actually this is FB wants something bad enough and Jens Axboe works for them.

wtallis 7y ago

> "relatively sane" because this isn't really asynchronous What's your criteria for "really asynchronous"? > it's just make-believe with a kernel-managed thread pool To the extent that io_uring uses anything resembling a thread pool, it seems to me that it is used completely differently from how a userspace AIO thread pool operates. When a userspace AIO implementation submits IO to the kernel, it does so with a blocking syscall and that thread stalls until that IO is complete. That means the number of outstanding IOs is limited by the number of threads in the pool. I don't see any such limitation in using io_uring to deliver IO requests to the block layer.

tyingq 7y ago
>What's your criteria for "really asynchronous" One example might be that related operations, like stat(), opendir(), readdir(), getpeername(), and so on...remain synchronous. And that async functionality is mostly a bolt-on to very established things, file descriptors, berkeley sockets etc. Also, every improvement is a pretty big patchset with code to ensure the traditional synchronous operations don't get unintended side effects. Just generally the idea that a "clean start", non-POSIX bound OS might design things differently, I imagine. Google's Fuchsia seems to hit some middle ground, where async is more foundational, for example. I don't think that observation detracts from the improvements.
- chriswarbo 7y ago
  > Just generally the idea that a "clean start", non-POSIX bound OS might design things differently, I imagine. Google's Fuchsia seems to hit some middle ground, where async is more foundational, for example. Microsoft's (research, discontinued) Midori OS was heavily async: http://joeduffyblog.com/2015/11/19/asynchronous-everything http://joeduffyblog.com/2015/11/19/asynchronous-everything
  - tyingq 7y ago
    That's exactly where I was going. Critisim of Linux async shouldn't be discouraged because of inherent limitations. That would hample innovation. I wouldn't be surprised by a new web server, API gateway, load balancer, etc, that mandated "forget about POSIX, adhere to this". The whole cloud abstraction movement seems to enable it.
- yxhuvud 7y ago
  statx exist as opcode, so stat through the ring is a solved problem. Directory operations are not implemented yet, but I'd be surprised if they don't arrive, sooner than later.
  - tyingq 7y ago
    I view that as confirmation of the GP observation. Async is an afterthought for Xnix.
blattimwind 7y ago
> I don't see any such limitation in using io_uring to deliver IO requests to the block layer. You can already have asynchronous IO from userspace to the block layer via linux-aio and O_DIRECT. But the VFS remains synchronous, so both uring and userspace can effectively only use a thread pool to work around that. Or magic.

mzs 7y ago

Actually this is FB wants something bad enough and Jens Axboe works for them.