Re: Les coroutines c'est bien, mais c'est pas la panacée

J'ai jamais pensé à répondre à ce commentaire, toutes mes excuses.
Je trouve affreusement verbeuse et lourde cette façon d'exécuter les requêtes justement. Pour un gros programme je peux comprendre l'investissement, mais là pour ce besoin c'est impossible.

Surtout, tu peux exécuter des requêtes en parallèle (tu peux avoir plusieurs threads qui gèrent un mainLoop avec le client partagé), ce qui est très difficile à faire correctement avec les coroutines, car justement lorsqu'une coroutine est en "await", elle est ininterruptible (vu que techniquement, elle n'existe même plus sur la pile d'appel).

Et je ne suis pas d'accord avec ce point. Alors certes je ne lance pas plusieurs threads, mais parce que ça ne sert à rien pour du code qui passe son temps à le perdre dans des appels externes. Mais sur l'un des écrans de l'utilitaire, je viens à l'instant de paralléliser la récupération des données. Le changement a ajouté une dizaine de lignes de code.
Le (pseudo-)code précédent était :

for (auto &&server: servers) {
 co_await fetchServerData(server);
 co_await fetchServerNetworkInfo(server);
 co_await fetchServerBillingInfo(server);
}

Le changement a été super simple : isoler le contenu de la boucle for dans une fonction, et passer par les signaux/slots plutôt que par un appel direct ou une coroutine.
ie

connect(this, &MyClass::requestServerInfo, this, &MyClass::fetchServerInfo);
for (auto &&server: servers) {
 emit requestServerInfo(server);
}

et fetchServerInfo est une coroutine reprenant à l'identique le code qui était dans la boucle for.

L'interruption des coroutines fait un retour à la boucle d'événements, qui va alors lancer la coroutine suivante. Ce qui permet donc de paralléliser les appels web derrière.