Io_uring is not (only) a generic asynchronous syscall facility

Re:Io_uring is not (only) a generic asynchronous syscall fac... by gpderetta on Wednesday June 30, 2021 @08:36AM (#27687695)

Note that the Disruptor is just one of the many applications for a ringbuffer, in particular is a multproducer-to-multicast best-effort link (i.e slow readers will miss packets), but not all ringbufer use cases can be covered by it.

In particular the disruptor wouldn't be appropriate to implement io_uring, where there is only one consumer, only one producer[1] and packet loss is not tolerated.

[1] some external synchronization can be course be used to handle multiple producers, but that's not io_uring concern.

[ Parent | on HN ]

Re:Io_uring is not (only) a generic asynchronous syscall fac... by bob1029 on Wednesday June 30, 2021 @08:50AM (#27687831)

> In particular the disruptor wouldn't be appropriate to implement io_uring

Completely agree. It's at a higher level of abstraction and intersects only in some conceptual ways with how the OS operates.

> [...] where there is only one consumer, only one producer[1] and packet loss is not tolerated.

My agreement above still standing, I feel like this case is actually covered by the disruptor as well. It is a trivial subset of the multi-producer, single-consumer problem that it was originally built to handle. If you made some minor modification like "packet loss is tolerated", then you have a solid case.

[ Parent | on HN ]