vayel / article-async Goto Github PK

N'ont pas encore été programmées pour être exécutées par la boucle,

Je ne comprends pas comment tu le détectes dans la fonction wait. Tu pars du principe qu'une instance de Task est nécessairement programmée dans la boucle ?

yield from wait([sub])

Je ne comprends pas pourquoi ça fonctionne. En fait, je ne comprends pas pourquoi example() ne quitte pas avant la fin de wait() alors qu'elle le fait avant celle de subtask() dans l'exemple 2.

Ajouter des exercices à https://github.com/ArnaudCalmettes/article-async/issues/4 et https://github.com/ArnaudCalmettes/article-async/issues/11 : on exécuterait des coroutines contenant des print et demanderait au lecteur de deviner l'ordre d'apparition des messages dans la console.

• https://github.com/ArnaudCalmettes/article-async/issues/7

Cependant, dans la pratique, on ne devrait pas avoir à manipuler directement la boucle pour réaliser quelque chose d'aussi simple que le lancement d'une tâche parallèle.

Serait-il possible d'expliquer brièvement pourquoi ? Un appel à event_loop.schedule me semble tout à fait pratique pour démarrer une tâche.

On peut créer, attendre ou arrêter un processus fils depuis n'importe quel processus en cours d'exécution.
Cette phrase est-elle équivalente à la suivante ?

On peut, depuis n'importe quel processus A en cours d'exécution, créer, attendre ou arrêter un processus fils de A.

Le cas échéant, je ne dis pas qu'il faut reformuler ainsi, seulement que ta phrase est vague pour ceux ignorant la notion de processus. En effet, on pourrait croire qu'il existe deux types de processus : les pères, et les fils. Ta phrase pourrait alors être comprise en "On peut créer, attendre ou arrêter n'importe quel processus fils depuis n'importe quel processus père en cours d'exécution.".

Par extension, on devrait pouvoir lancer, attendre la fin de l'exécution, ou annuler une « sous-coroutine » depuis n'importe quelle coroutine en cours d'exécution, sans avoir à appeler la méthode schedule() ni même toucher directement à la boucle événementielle.

Sans prendre en compte ma toute première remarque, je comprends ce qui suit la seconde virugle ("sans avoir à appeler la méthode..."), mais pas trop le début : pourquoi voudrait-on appeler une coroutine depuis une autre ?

Tu vas sûrement me détromper, mais tu pourrais suivre le raisonnement suivant.

• Cas concret
• Dans cette situation, on a besoin d'appeler une « sous-coroutine »
• On pourrait le faire directement via schedule()
• Mais... (cf. première remarque)
• On va donc plutôt adopter le fonctionnement des OS

la coroutine example utilise cette syntaxe pour laisser temporairement la main à la coroutine subtask

notre but, ici, est de réussir à lancer la coroutine subtask de façon qu'elle s'exécute en parallèle de la coroutine example, et non d'attendre que subtask soit terminée pour reprendre l'exécution de example.

Ce ne sont pas des coroutines, mais des fonctions coroutines. Il suffit de rajouter des parenthèses. ^^

>>> # La coroutine vient de nous envoyer un message.
... # On lui répond.
...

Le format est un peu bizarre. Au début, je croyais que les points de suspension signifiaient un etc.

Comme vous le constatez, la syntaxe de Python rend assez intuitif le fait que notre coroutine peut envoyer des requêtes à son environnement d'exécution, et se suspendre jusqu'à ce qu'on lui envoie le résultat de cette requête.

Si j'ai bien compris, quand on arrive à la ligne data = yield 'REQUÊTE', il se passe cela :

1. On "retourne" la chaîne 'REQUÊTE' (pourquoi passer à du français ?)
2. On attend un send
3. Quand il arrive, on stocke la valeur dans la variable data "de la même ligne que le yield du 1"

# L'appel à CALL_SCHEDULE retourne un tuple à un seul élément dans ce cas

J'imagine que c'est pour coller avec asyncio que ensure_future ne prend qu'une seule tâche ? Pourquoi ne pas avoir un *args ?

lance l'exécution d'une coroutine de en parallèle

Petit "de" en trop.

Par exemple, si nous rendions la tâche subtask plus longue qu'example, celle-ci lui « survivrait »

Je ne comprends pas trop ce que tu veux dire par « survivrait ». Avant de lire l'exemple, je pensais justement que cela voulait dire qu'on avait pas à appeler event_loop.run_until_empty.

Cela dit, on peut aussi imaginer tout simplement vouloir attendre de façon asynchrone que la sous-tâche ait terminé son exécution avant de quitter proprement…

J'allais dire qu'on aurait pu appeler directement run_until_empty, mais cela aurait nécessiter d'ajouter manuellement la première tâche via schedule. Peut-être pourrais-tu faire la remarque et dire que, pour ne pas utiliser directement schedule, on va implémenter wait.