Skip to main content

io_engine/
context.rs

1use crate::callback_worker::Worker;
2use crate::driver::aio::AioDriver;
3use crate::driver::uring::UringDriver; // Import UringDriver
4use crate::tasks::{IOCallback, IOEvent};
5use crossfire::BlockingRxTrait;
6use std::io;
7
8pub enum Driver {
9    Aio,
10    Uring,
11}
12
13/// Setup the submission of IO tasks to the underlying driver.
14///
15/// It is generic over the callback type `C`, the submission queue `Q`, and the worker type `W`.
16///
17/// # Channel Selection for `W` (Worker)
18///
19/// When configuring the worker `W` (usually a channel sender `cb_workers`),
20/// you should choose the `crossfire` channel type based on your sharing model:
21///
22/// * **Shared Worker (Multiple Producers):** If you have multiple submission channels sharing the same
23///   callback worker, use the [IOWorkers](crate::callback_worker::IOWorkers) struct,
24///   or pass `crossfire::MTx` (from `mpsc` or `mpmc` channels) with your custom worker implementation.
25///   This allows multiple producers to send completion events to a single consumer (worker).
26///
27/// * **Single Instance (Dedicated Worker):** If you have a single submission channel with its own dedicated
28///   callback worker, use `crossfire::Tx` (from `spsc` channels). This is more efficient for single-producer
29///   scenarios.
30///
31/// * **inline callback:** If you have a very light callback logic, you can use [Inline](crate::callback_worker::Inline)
32pub fn setup<C, Q, W>(
33    depth: usize,
34    rx: Q,
35    cb_workers: W,
36    driver_type: Driver, // New parameter
37) -> io::Result<()>
38where
39    C: IOCallback,
40    Q: BlockingRxTrait<Box<IOEvent<C>>> + Send + 'static,
41    W: Worker<C> + Send + 'static,
42{
43    match driver_type {
44        Driver::Aio => AioDriver::<C, Q, W>::start(depth, rx, cb_workers),
45        Driver::Uring => UringDriver::<C, Q, W>::start(depth as u32, rx, cb_workers),
46    }
47}