tokio-uring
tokio-uring copied to clipboard
tokio-rs
add probe io-uring support
It is a useful wrapper. Avoid users of the tokio-uring to rely on the
io-uring library themselves.
Signed-off-by: wanglei01 [email protected]
Why are so many files being touched.
The src/driver/mod.rs file is a wrapper around io-uring, all operations on io-uring should be implemented in this module. But is it appropriate to release the exposed interface to Runtime? Or under lib.rs? I don't have any good ideas.
The work could be in driver but the API could be exposed by the top lib.rs if I understand correctly. But before doing more actual implementation, maybe pass on a thought of what the API for keeping all the probe results would be. Personally, I would be okay if the state weren't kept at all by the library and if the user wants to ask more than once, they have the work done more than once. The less state kept by the library, the easier it is to understand and the fewer opinions it needs to have baked in. There's also the option of a helper module that the driver doesn't rely on but that the user can invoke if it helps standardize a common pattern, like probe results.
It's small, but there probably isn't a need for the library to hold many memory of what the probe results were. Some users will want to keep the data, perhaps for sharing between current threads, perhaps for deciding at runtime what calls to make for a given feature. Others will check once and then not need the data any more.
So I guess I'm leaning towards just supporting the call to probe and returning the results with some kind of boolean tests coded against the probe results, again so the io_uring driver and its opcodes, don't need to be exposed to the user.
Hi @FrankReh. I have re-implemented it.
But when I used tokio::sync::OnceCell, I got a problem. The user uses the io_uring_probe function, there may not be an async context. It may happen before the user creates the tokyo-uring::Runtime. If the kernel does not support io-uring, the user may choose to create tokio::Runtime.
Have time to review it? Thanks.
If this is ok, I will complete all supported functions.
I'm not willing to accept this PR right now, as we haven't had much discussion on how probing should work semantically. I'd recommend converting this into a draft PR and opening an issue for us to discuss probe semantics. In particular, I'm wondering if probing may be something best done at startup and stored in the runtime, and used to potentially modify runtime behavior or enable/disable certain APIs.
