Qt's networking code has always been one of its more obtuse parts, requiring using signals for something that didn't quite seem right for them. A linear flow of code would become a jumbled mess of member functions and signal connections.
When developing Challah's netcode, I quickly realised this wasn't going to suffice for the large amount of it I was going to be writing. Thus begins my journey through signal hell, arriving at many bumps before I discovered that integrating Qt's networking stuff with coroutines is possible.
Stop Zero
If you're just here to see some cool coroutine code, you can look at https://invent.kde.org/-/snippets/1711 for an single-file version of the tutorial in this blog-post, with a coroutine function already made and ready for you to play with. If you want something more full-fledged, look at https://invent.kde.org/cblack/coroutines.
But if you want to know what's actually going on behind the scenes, continue reading.
Stop One: Don't Do This
Approach one that I took to get out of signal hell was a simple while loop:
while (!reply->isFinished()) {
QCoreApplication::processEvents();
}
This is a bad idea. Strange graphical glitches, bugs, crashes, etc. lie behind this innocuous code. Don't do it. Forcibly spinning the event loop in a lot of places causes a lot of bugs.
Step Two: Callback Hell
So, what do you do if you want to write somewhat linear code without doing that? Callbacks.
QObject::connect(val, &QNetworkReply::finished, [val, callback]() {
if (val->error() != QNetworkReply::NoError) {
val->deleteLater();
callback({QStringLiteral("network failure(%1): %2").arg(val->error()).arg(val->errorString())});
return;
}
auto response = val->readAll();
protocol::chat::v1::CreateGuildResponse ret;
if (!ret.ParseFromArray(response.constData(), response.length())) {
val->deleteLater();
callback({QStringLiteral("error parsing response into protobuf")});
return;
}
val->deleteLater();
callback({ret});
return;
});
Every time I had to call into the netcode, I would have to provide a std::function<void(std::variant<Result,Error>)>. It's passable for a single call, but chaining them quickly violates “happy path sticks to the left”, making you wonder if you're actually writing Python with how far indented your code is.
c->call([c](auto response) {
c->call([c](auto response) {
c->call([c](auto response) {
c->call([c](auto response) {
c->call([c](auto response) {
});
});
});
});
});
Not good.
Step Three: Out of the Inferno, Into the Frying Pan
await/async as a mechanic in languages generally reduces the amount of callback hell you face by sugaring it for you. For example, in JS, this:
return fetch().then((it) => {
return it.text
})
is equivalent to this:
return await fetch().text
Both of these return the exact same thing to the caller, but one is much easier to deal with when chained.
For a while, C++ didn't have this. Of course, with C++20, coroutines with co_await & company are now available* in most compilers.
Diversion: That Asterisk
Coroutines are technically available in most compilers, but you're going to have to do a lot of compiler-specific dances in both your code and the build system in order to pass the correct flags to enable coroutines.
I use this snippet to handle clang & gcc:
#if defined(__clang__)
#include <experimental/coroutine>
namespace ns = std::experimental;
#elif defined(__GNUC__)
#include <coroutine>
namespace ns = std;
#endif
where ns is aliased to the namespace containing coroutine-related stuff. Also note that clang will probably fail to compile stuff due to experimental/coroutine being part of libc++ while the rest of your system probably uses gcc's libstdc++. So, for all intents and purposes, gcc is your only option with coroutines on Linux.
Anyways...
Unhelpful Documentation
When hacking on coroutines, I quickly realised: the available documentation on what they were was both young and immature, as well as unhelpful in what they did have. So, this blog post is going to document them.
Parts of the Coroutine
Coroutines are largely split into two parts: the “promise” and the “awaitable”.
The promise is responsible for handling the “internal” side of any coroutine: it's what provides the return value, its yield behaviour, handling unhandled exceptions, the “await transformer”, and some other things. All coroutines need to return a type associated with one of these.
The awaitable handles the “external” side of the coroutine being co_awaited: it checks with the outside world whether or not the coroutine needs to suspend, listening to the outside world and reactivating the coroutine when it's ready, and providing the value received from the coroutine's completion.
As far as stuff that's directly interacting with coroutines goes, that's mostly it. However, there's still one type you need for an end-user API: the type returned by a coroutine, which is what the compiler uses to match your coroutine to a promise type.
SomeType a_coroutine() {
auto foo = co_await another_thing();
// ...
}
This SomeType is what I will be calling the “future” or the “task” type, as it's basically the QFuture of the QPromise (or QFutureInterface to speak in Qt5 parlance).
C++ coroutines are very much “bring your own runtime and types”, and thankfully, that's what Qt already has, making it perfect for integrating into coroutines.
A QML-friendly future
C++ coroutines are the perfect fix to a long-standing issue in QML: representing asynchronous results in the UI in a manner that being an object property or model data can't.
So, let's get to constructing the base of our coroutines, and a type that will be suitable for passing into QML.
For ease of use, we'll want this done as a copyable Q_GADGET type with implicitly shared data. This will help us later down the road when we're passing the future type through lambdas.
(For the sake of simplicity of teaching how coroutines work, I'll be doing a simple non-template future type that talks in QVariants and doesn't have success/failure states. If you want to see code with more type safety and success/failure states, you can check out https://invent.kde.org/cblack/coroutines.)
We'll start by defining our shared data & behaviour.
class Future
{
Q_GADGET
struct Shared {
QVariant result;
std::function<void(QVariant)> then = [](QVariant) {};
bool done = false;
};
QSharedPointer<Shared> d;
public:
Future() {
d.reset(new Shared);
}
Future(const Future& other) {
this->d = other.d;
}
};
This gives us a Future that is effectively a blob. First, let's define getters for done and result, so the outside world can actually tell what the current state of the Future is:
bool settled() const {
return d->done;
}
QVariant result() const {
return d->result;
}
Now we need a way to say that the future is completed and a result is available.
void succeed(const QVariant& value) const {
if (d->done) {
return;
}
d->done = true;
d->result = value;
d->then(d->result);
}
We don't want to trigger the callback again if we've already marked the future as done, so we abort early if we're already done.
You may notice that this function, despite being a setter semantically, is marked as const. This is mostly for ease of dealing with in lambdas later on.
Now, we need a way to register the callback function in the C++ side of things.
void then(std::function<void(QVariant)> then) const {
d->then = then;
if (d->done) {
then(result());
}
}
If the future is already done and you register a callback, you want to call it immediately. This is to handle situations like this:
Future fetch() {
if (cache.has_thing()) {
Future future;
future.succeed(cache.get_thing();
return future;
}
// ...
}
void main() {
fetch().then([](QVariant) {
});
}
If we didn't invoke the callback in then(), the callback would never be triggered as the future was returned to the caller in an already succeeded status.
Since I promised a QML-friendly future type, we should implement that now.
Q_INVOKABLE void then(const QJSValue& it) {
then([va = it](QVariant result) mutable {
va.call({va.engine()->toScriptValue(result)});
});
}
We add a Q_INVOKABLE overload that takes a QJSValue, as JS functions are represented as QJSValues in C++. We then have a lambda which we pass back into the other then function, taking the QVariant, transforming it into a QJSValue, and calling the JavaScript callback with the variant.
JS usage looks like this:
future.then((it) => {
console.warn(it)
})
If you've been following along, you should now have this class:
class Future
{
Q_GADGET
struct Shared {
QVariant result;
std::function<void(QVariant)> then = [](QVariant) {};
bool done = false;
};
QSharedPointer<Shared> d;
public:
Future() {
d.reset(new Shared);
}
Future(const FutureBase& other) {
this->d = other.d;
}
bool settled() const {
return d->done;
}
QVariant result() const {
return d->result;
}
void succeed(const QVariant& value) const {
if (d->done) {
return;
}
d->done = true;
d->result = value;
d->then(d->result);
}
void then(std::function<void(QVariant)> then) const {
d->then = then;
if (d->done) {
then(result());
}
}
Q_INVOKABLE void then(const QJSValue& it) {
then([va = it](QVariant result) mutable {
va.call({va.engine()->toScriptValue(result)});
});
}
};
The Backing Promise
Of course, the above class doesn't make a coroutine. For this, we need to implement the promise type.
For placement options, you have two places where you can put this: inside the future type itself, or outside of the type in an explicit coroutine_traits template specialisation.
The former would look like this:
class Future {
// ...
struct promise_type {
};
};
While the latter would look like this:
template<typename ...Args>
struct ns::coroutine_traits<Future, Args...> {
struct promise_type {
};
};
(where ns is the namespace with the coroutine types, std:: on gcc or std::experimental on clang.)
The latter allows you to implement a promise type for any type, not just one that you have control of the declaration of.
For this blog post, I'll be going with the latter approach.
struct promise_type {
};
One of the things we'll need in our promise type is a member variable to hold the future type.
struct promise_type {
Future _future;
};
Of course, the compiler doesn't know about this member variable, so we need to start implementing the promise_type interface:
struct promise_type {
Future _future;
Future get_return_object() noexcept {
return _future;
}
};
T get_return_object() noexcept is the exact type signature that needs to be implemented. We use noexcept here, as exceptions can cause a double free, and therefore, a crash.
Now, we need to implement two things: initial_suspend() and final_suspend(). These two functions are called at the start and end of your coroutine, and have to return a co_awaitable type.
In an expanded form, initialsuspend and finalsuspend look like this:
Future your_coroutine() {
co_await promise.initial_suspend();
// coroutine body here...
co_await promise.final_suspend();
}
You could theoretically return anything you want here, but you'll likely be sticking with ns::suspend_never, which is an awaitable value that resumes execution of the coroutine immediately when co_awaited, and what we'll be using for this blog post.
Add the implementation to your promise type:
ns::suspend_never initial_suspend() const noexcept { return {}; }
ns::suspend_never final_suspend() const noexcept { return {}; }
Your promise is responsible for taking care of any values that are co_returned with the return_value function.
I recommend having two overloads: const T& (copy value) and T&& (move value).
For our promise_type, the implementation of those will simply look like this:
void return_value(const QVariant& value) noexcept
{
_future.succeed(value);
}
void return_value(QVariant &&value) noexcept
{
_future.succeed(std::move(value));
}
If your coroutine was returning something like a std::unique_ptr<T>, you would need the std::move in order to properly handle it, and thus why I say you should have this overload in your promise type.
With getreturnobject, initialsuspend, finalsuspend, and return_value, you only have one remaining function left to implement in your coroutine. It's quite simple.
void unhandled_exception() noexcept {
}
This is what gets called in the catch block of a try/catch block catching exceptions that the coroutine might throw. Use std::current_exception() to access the exception.
For this blog post, we'll simply be doing Q_ASSERT("unhandled exception"); in our implementation.
With that, the promise type is complete. It should look something like this:
struct promise_type {
Future _future;
Future get_return_object() noexcept {
return _future;
}
ns::suspend_never initial_suspend() const noexcept { return {}; }
ns::suspend_never final_suspend() const noexcept { return {}; }
void return_value(const QVariant& value) noexcept
{
_future.succeed(value);
}
void return_value(QVariant &&value) noexcept
{
_future.succeed(std::move(value));
}
void unhandled_exception() noexcept {
Q_ASSERT("unhandled exception");
}
};
Remember that this needs to be within the Future type itself, or within the appropriate coroutine_traits overload.
The Awaitable
With the Future and promise completed, we don't have much left to do. We now need to implement operator co_await(Future) in order to allow the Future to be awaited.
Technically, we don't need the promise type to make a Future awaitable, only the Future and the co_await overload. Implementing a promise type allows your coroutine that's co_awaiting a Future to return another Future.
There's not really much to the co_await overload, so I'll just paste an implementation verbatim:
auto operator co_await(Future it) noexcept
{
struct Awaiter {
Future future;
bool await_ready() const noexcept {
return future.settled();
}
void await_suspend(ns::coroutine_handle<> cont) const {
future.then([cont](QVariant) mutable {
cont();
});
}
QVariant await_resume() {
return future.result();
}
};
return Awaiter{ it };
}
co_await needs to return a type with the following methods:
bool await_ready() const noexcept: This function is called before suspending the coroutine to wait on the awaitable to resolve. If the function returns true, the coroutine continues execution without suspending. If the function returns false, it suspends and waits on the value.
Think back to the example of a function returning an already succeeded future to see why this is useful. If the future already holds a value, there's no need to waste time suspending the coroutine.
void await_suspend(ns::coroutine_handle<> callback) const: This function is called when the coroutine suspends with a coroutine handle passed in. For all intents and purposes, you can treat it as if it were a std::function holding a callback, except operator () resumes the coroutine instead of calling a function.
You call the coroutine_handle to resume the coroutine when whenever it's waiting on is ready, e.g. when the future in this example is marked as succeeded. You can connect this to just about anything, e.g. a QTimer::singleShot, a signal, using it as a callback, etc.
T await_resume() const: This is the value that gets assigned to the result of co_awaiting the expression:
auto it = co_await fetchFromNetwork();
// |
// ^ this is the value from await_resume()
Annd with all three types implemented, you now have a QML-friendly future, a promise, and an awaitable.
A Brand New Washing Machine
With your new coroutine, you can do just about anything asynchronously. This is an example function that returns a future that will be fufilled in N miliseconds:
Future timer(int duration) {
Future it;
QTimer::singleShot(duration, [it]() {
it.succeed({});
});
return it;
}
Note that while it returns a Future, it is not a coroutine. It does not co_await. This is a completely normal function that you can call however you desire.
Making a coroutine using this function is easy:
Future thisIsACoroutine() {
co_await timer(2000);
co_return {};
}
Note that this function could not return void. The return type of a coroutine has to have an associated promise type, which void does not.
In a class exposed to QML...
class Singleton : public QObject
{
Q_OBJECT
public:
Q_INVOKABLE Future foo() {
co_await timer(2000);
co_return "i was returned by a coroutine";
};
};
This can be used like so:
Button {
anchors.centerIn: parent
text: "a coroutine!"
onClicked: Singleton.foo().then((val) => {
console.warn(val)
})
}
This will output the following in your console 2 seconds after every time you press this button:
qml: "i was returned by a coroutine"
The inline code from this blog post can be found in a single-file format at https://invent.kde.org/-/snippets/1711. Compile with C++20 and -fcoroutines-ts -stdlib=libc++ for clang, and -fcoroutines for gcc.
For a basic future+promise+awaitable deal, this is about all you need to know. However, the iceberg gets way deeper than that.
Stay tuned for more blog posts about the eldritch arcana you can pull off with coroutines. Next one will probably be about wrapping already-existing types such as a QNetworkReply* in order to make them co_await-able.
You can see more advanced (and arguably useful) code at https://invent.kde.org/cblack/coroutines.
Note that I wrote this blog post at 2 in the morning. If there's anything that doesn't make sense, please feel free to come to me and ask for clarification.
Or, want to talk to me about other coroutine stuff I haven't discussed in this blog post (or anything else you might want to talk about)?
Contact me here:
Telegram: https://t.me/pontaoski
Matrix: #pontaoski:tchncs.de (prefer unencrypted DMs)
Tags: #libre
anjanik012
clau-cambra
