runtime-core: network and faults - #5708
Conversation
| Poll::Ready(output) => output, | ||
| Poll::Pending => unreachable!("task.is_finished() was true"), | ||
| }; | ||
| if let Some(output) = poll_finished_task(&mut task) { |
There was a problem hiding this comment.
So if future completes immediately, no other task has a chance to run, right?
This does not seem quite correct to me in the presence of I/O -- the OS runs it in parallel, even if we have a single-threaded async runtime in the application. Which means that spawned tasks could become runnable while the runtime is blocked on future.
From tokio docs on Runtime::block_on and Handle::block_on it seems like I/O is always a separate thread, even in the current thread runtime. We probably don't want that, but then we also can't have nested block_on calls.
So I guess there needs to be some budget of I/O that needs to be run even in the immediately-ready case?
There was a problem hiding this comment.
This does not seem quite correct to me in the presence of I/O.
My idea is that if there is an I/O. Task will always return Poll::Pending (Basically all I/Os must have some wait time). Hence, there will be some loop cycles before finishing.
we also can't have nested block_on calls.
This is actually, I am still evaluating if we can have nested block_ons. It looks wrong but not obvious to me. Why do you think we can't?
There was a problem hiding this comment.
I think the affect would be, runtime will stuck on nested block_on until it completes, but nested one will still be able to poll all other tasks.
Note that, It will not be possible if we do tasks queue per Node.
|
|
||
| let mut progressed = false; | ||
| for _ in 0..budget { | ||
| let Some(runnable) = self.queue.try_recv_random(&self.rng) else { |
There was a problem hiding this comment.
One thing I was wondering about before: would it not make sense to have a task queue per node? We could model slow nodes then by biasing task selection towards fast nodes.
I get that pause has a similar effect (paused tasks re-enter the queue on unpause, and we're selecting tasks randomly), my worry is more that it could be difficult to deduce certain failure patterns from a failed run or design tests with specific patterns 😅
There was a problem hiding this comment.
I was actually thinking to move in that direction too.
2 participants
Description of Changes
API and ABI breaking changes
NA
Expected complexity level and risk
2-3