8.13. Contrôle de la boucle¶

La plupart des scripts asyncio ne touchent jamais directement à la boucle d’événements – asyncio.run() suffit. Cette page couvre l’interface Loop pour les cas où ce n’est pas le cas : installer un gestionnaire d’exceptions, exécuter la boucle avec un cycle de vie différent de run, ou conserver l’objet boucle à des fins d’instrumentation.

8.13.1. Obtenir la boucle¶

asyncio.get_event_loop() – renvoie l’objet Loop. Peut être appelé en toute sécurité depuis l’intérieur ou l’extérieur d’une coroutine.
asyncio.new_event_loop() – sur MicroPython, réinitialise l’état de la boucle existante au lieu d’en créer une nouvelle. La remarque mérite d’être répétée : il y a exactement une boucle d’événements par programme.

Il n’existe aucune API pour exécuter la boucle autre que les méthodes de Loop et asyncio.run().

8.13.2. Exécuter la boucle directement¶

asyncio.run() est le bon point d’entrée pour presque toutes les applications. Deux méthodes de Loop existent pour les cas où ce n’est pas le cas.

run_until_complete() – étant donné un awaitable, exécute la boucle jusqu’à ce que cet awaitable se termine, puis renvoie son résultat. Équivalent à un seul appel à asyncio.run(), sans le démantèlement de la boucle.
run_forever() – exécute la boucle jusqu’à ce que stop() soit appelé depuis l’intérieur d’une tâche. Pas d’awaitable de premier niveau ; l’application est censée planifier tout ce dont elle a besoin via asyncio.create_task() avant d’appeler run_forever.

Les méthodes associées sont stop() (demande à la boucle de s’arrêter après la fin de la tâche courante) et close() (libère les ressources de la boucle).

8.13.3. Création de tâches côté boucle¶

create_task() – même opération que asyncio.create_task(). La fonction libre existe pour que le code applicatif n’ait pas besoin d’une référence à la boucle dans le cas courant ; la méthode existe pour l’instrumentation qui en possède déjà une.

8.13.4. Gestionnaires d’exceptions¶

La boucle appelle un gestionnaire lorsqu’une tâche lève une exception que rien dans la chaîne d’appel de la coroutine n’a interceptée – un cas typique étant une tâche que l’application a créée avec asyncio.create_task() et n’a jamais attendue. Le gestionnaire par défaut affiche une trace d’appels via sys.stderr ; la page sur les exceptions a montré comment le remplacer par un gestionnaire personnalisé.

set_exception_handler() – installe un gestionnaire personnalisé. Le gestionnaire est un appelable handler(loop, context) où context est un dictionnaire contenant au moins 'message' et généralement 'exception' et 'future'.
get_exception_handler() – renvoie le gestionnaire actuellement installé, ou None si celui par défaut est utilisé.
default_exception_handler() – le gestionnaire intégré. Utile à l’intérieur d’un gestionnaire personnalisé qui souhaite aussi exécuter le comportement par défaut (journaliser dans la mémoire flash et afficher une trace d’appels, par exemple).
call_exception_handler() – exécute le gestionnaire actuellement installé avec un dictionnaire de contexte construit à la main. Utilisé principalement par la boucle elle-même ; une application en a rarement besoin.