runtime: I/O API + simulator - #5658
Conversation
Entails making it Send + Sync, which may or may not be what we want.
| /// in either the submission or completion queue. | ||
| pub fn tick(&self, rng: &Rng) -> bool { | ||
| let mut progress = false; | ||
| for _ in 0..self.config.max_submissions_per_tick { |
There was a problem hiding this comment.
In my network side implementation, I have taken a different approach (inspired from tigerbeetle), added duration_at field to events/ops. Which has Driver induced randomness injected from config.
I think for this will translate here like, individual Disk IO ops to have duration_at field, which needs to be expired for events to go in completion queue.
I am wondering if we do duration_at for Disk IO (which we should) then whether current io::Config would be any useful? It doesn't look like both approaches compliments each other.
Also, I have made my Network tick just to waker.wake() all expired tasks every time, as randomness is induced by duration_at itself and further run_all_ready also picks the tasks randomly to poll.
Wdyt?
2 participants
Adds an
io-uring-compatible (file) I/O API with simulator and tokio impls.The DST runtime uses the simulator to drive I/O operations and inject failures according to a configuration. Failure injection is more or less for demonstration purposes, and may need to become more sophisticated for actual DST.
It is not yet clear how the application-facing API should look like: in any case, we will need a way to enter the runtime context.