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.