Hi all! I've been playing with C++ coroutines for a few months now.
At first, I started building an async runtime based on
io_uring to better understand the model of C++ stackless coroutines, and I was amazed by writing asynchronous code that feels just as clean and readable as other languages. Soon, I want to go beyond that and see how far the coroutine model can go in simplifying asynchronous programming. So, I decided to build an asynchronous Redis client library on top of my runtime.During building the Redis client library, I quickly realized that my runtime was missing some utilities for complex workflows, such as the
when_all and when_any combinators. But this was resolved quickly under the strong expressive ability of C++ coroutine model, and I finally achieved the simple interface as exactly what I am expecting like this:auto _1, _2, _3, exec_res = coawait redis.multi()
.set("user:{1001}", "val1")
.set("item:{1001}", val2)
.exec();
I've been experimenting with different task types via `promisetype
throughout this process, and gained a much deeper understanding of the mechanics behind Awaiter and std::coroutinehandle<>.` So I’m now convinced that the current C++ coroutine model has greatly reduced the complexity of asynchronous programming, **except for the……****Cancellation**
Cancel a single IO such as the `recv/send` seems to be straightforward as the runtime already provides that function. However, things get tricky when you try to extend this ability to a task level. For instance:
*Considering Task A is awaiting B or C, and C will await D (A->B/C->D)*
In this case, registering every single IO in the async call tree to cancel manually will be a nightmare, we might just want to call A.cancel() or derive a canceltoken from A instead of checking what exactly single IO is in D. Also, The cancellation of C might not affect the B but do cancel the D.
`std::execution` describes the `stoppabletoken
and setstopped()` to achieve this goal, while it requires very careful implementation of **each** receiver to check the stop token. The coroutine-based IO suggests that the token might be hidden within the `promisetype,as long as the root suspended nodes remember to check if it is stopped and register its callback in the call chain with some tricks in \await_suspend` and `await_transform()` like:template<class Promise>
bool awaitsuspend(std::coroutinehandle<Promise> h){
if constexpr( requires{ h.promise().hook(this); } ){
bool stopped = h.promise().hook(this);
if(stopped){ return false; }
}
}
It is hard to tell which method is "better" because the cancellation itself is actually scenario-dependent and outside the language core, yet currently I am accepting the second method as it fits my coroutine-based runtime simply. For instance, image that you are awaiting commands to the Redis server, it is hard to give a good definition about the cancellation of that operation, as the TCP packets might already reach the server side.
So, in a word, you can achieve a lot with the C++20 coroutine model nowadays, but we still have a lot of open questions to resolve in the asynchronous programming.
My Repo if you are interested in.
https://redd.it/1u1y6ep
@r_cpp
