Restructuring

[ollie-etl]

@thomasbarrett I'm a fan of https://github.com/thomasbarrett/io-uring-async, and its made me think about the structure of this library, and hwere it could go

Splitting the runtime, and the Ops apart, into seperate crates seems like a good idea. That allows for a decoupling in API experiments. I think what this repo has shown is that the API for a high level library around io-uring is still in flux.

On reflection, i'm not sure the distinction between the runtime in https://github.com/thomasbarrett/io-uring-async and here is all that great. Its not independent, because of the need for on thread park work. What i do like though is relying on the underlying runtime to implment async drop functionality, rather than doing it manually.

One thing which I think we should do, which we don't do in both libraries, is keep reference counts to the underlying ring in all submitted ops. I think we should we should do that to enable better cancellation support, now io_uring has cancel operations available.

@thomasbarrett, do you have an interest is exploring that design space?

[ileixe]

Decoupling runtime and ops is good idea as I've found current implementation is still far from optimal. After some performance inspections, I am getting more impression that we may need whole different way to use optimal workload patterns.

Personally, I want to explore simple alternative runtime without epoll (so pure uring based even for readiness device) and use uring enter + wait for a tick. Axobe also mentioned this is design choice to be efficient event loop in https://github.com/axboe/liburing/wiki/io_uring-and-networking-in-2023#batching

[ollie-etl]

Personally, I want to explore simple alternative runtime without epoll (so pure uring based even for readiness device) and use uring enter + wait for a tick. Axobe also mentioned this is design choice to be efficient event loop in

I've given this some thought, after investigating the implmentation in here and by https://github.com/thomasbarrett/io-uring-async, which is very similar. Both use a listener on the a tokio epoll backed AsyncFd to wake the thread.. I believe the change shouldn't be too hard to arrange - I think it's as simple as replacing the on_thread park method, which currently called submit, with submit and wait. I intend to give that a go.