Hi, there seems to be a fundamental difference between how Asio and Capy protect its users against async operations that are always ready. Asio uses default rescheduling and will not call the continuation inline even if the completion is synchronous. This is valuable for the safety of internet facing code e.g. a malicious client can't starve other tasks by sending data continuously. Capy on the other hand uses symmetric transfer to deal with synchronous completions, allowing the task to monopolize the event loop as long as data is available. IMO it is not safe enough to delegate yielding into the event loop to users as forgetting to do so creates vulnerability. It is safer to provide a way out of default rescheduling than requiring every user to do it manually. The problem is not a theoretical one and widely used runtimes such as Tokio had to correct course to avoid it [1]
If data is received faster than it can be processed, it is possible that more data will have already been received by the time the processing of a data chunk completes. In this case, .await will never yield control back to the scheduler, other tasks will not be scheduled, resulting in starvation and large latency variance.
Currently, the answer to this problem is that the user of Tokio is responsible for adding yield points in both the application and libraries. In practice, very few actually do this and end up being vulnerable to this sort of problem.
I would like to know why Corosio/Capy authors decided to take this direction? Marcelo [1] https://tokio.rs/blog/2020-04-preemption