Programmer avec *asyncio*
*************************

La programmation asynchrone est différente de la programmation «
séquentielle » classique.

Cette page liste les pièges et erreurs communs que le développeur
pourrait rencontrer et décrit comment les éviter.


Mode débogage
=============

Par défaut, *asyncio* s'exécute en mode production. Pour faciliter le
développement, *asyncio* possède un « mode débogage ».

Il existe plusieurs façons d'activer le mode débogage de *asyncio* :

* en réglant la variable d’environnement "PYTHONASYNCIODEBUG" à "1" ;

* en utilisant le mode développement de Python (Python Development
  Mode) ;

* en passant "debug=True" à la fonction "asyncio.run()" ;

* en appelant la méthode "loop.set_debug()".

En plus d'activer le mode débogage, vous pouvez également :

* régler le niveau de journalisation pour l'enregistreur d'*asyncio*
  (asyncio logger) à "logging.DEBUG" ; par exemple, le fragment de
  code suivant peut être exécuté au démarrage de l'application :

     logging.basicConfig(level=logging.DEBUG)

* configurer le module "warnings" afin d'afficher les avertissements
  de type "ResourceWarning" ; vous pouvez faire cela en utilisant
  l'option "-W" "default" sur la ligne de commande.

Lorsque le mode débogage est activé :

* *asyncio* surveille les coroutines qui ne sont jamais attendues et
  les journalise ; cela atténue le problème des « *await* oubliés » ;

* beaucoup d'*API* *asyncio* ne prenant pas en charge les fils
  d'exécution multiples (comme les méthodes "loop.call_soon()" et
  "loop.call_at()") lèvent une exception si elles sont appelées par le
  mauvais fil d’exécution ;

* le temps d'exécution du sélecteur d'entrée-sortie est journalisé si
  une opération prend trop de temps à s'effectuer ;

* les fonctions de rappel prenant plus de 100 ms sont journalisées ;
  l'attribut "loop.slow_callback_duration" peut être utilisé pour
  changer la limite (en secondes) après laquelle une fonction de
  rappel est considérée comme « lent ».


Programmation concurrente et multi-fils
=======================================

Une boucle d'évènements s'exécute dans un fil d’exécution (typiquement
dans le fil principal) et traite toutes les fonctions de rappel
(*callbacks*) ainsi que toutes les tâches dans ce même fil. Lorsqu'une
tâche est en cours d'exécution dans la boucle d'évènements, aucune
autre tâche ne peut s'exécuter dans ce fil. Quand une tâche traite une
expression "await", elle se suspend et laisse la boucle d’évènements
traiter la tâche suivante.

Pour planifier un *rappel* depuis un autre fil d'exécution système,
utilisez la méthode "loop.call_soon_threadsafe()". Par exemple :

   loop.call_soon_threadsafe(callback, *args)

La plupart des objets *asyncio* ne sont pas conçus pour être exécutés
dans un contexte multi-fils (*thread-safe*) mais cela n'est en général
pas un problème à moins que l'objet ne fasse appel à du code se
trouvant en dehors d'une tâche ou d'une fonction de rappel. Dans ce
dernier cas, si le code appelle les *API* bas niveau de *asyncio*,
utilisez la méthode "loop.call_soon_threadsafe()". Par exemple :

   loop.call_soon_threadsafe(fut.cancel)

Pour planifier un objet concurrent depuis un autre fil d'exécution
système, utilisez "run_coroutine_threadsafe()". Cette fonction renvoie
un objet "concurrent.futures.Future" pour accéder au résultat :

   async def coro_func():
        return await asyncio.sleep(1, 42)

   # Later in another OS thread:

   future = asyncio.run_coroutine_threadsafe(coro_func(), loop)
   # Wait for the result:
   result = future.result()

Pour pouvoir traiter les signaux et démarrer des processus enfants, la
boucle d'évènements doit être exécutée dans le fil principal.

La méthode "loop.run_in_executor()" peut être utilisée avec
"concurrent.futures.ThreadPoolExecutor" pour exécuter du code bloquant
dans un autre fil d'exécution, afin de ne pas bloquer le fil où la
boucle d'évènements se trouve.

There is currently no way to schedule coroutines or callbacks directly
from a different process (such as one started with "multiprocessing").
The Méthodes de la boucle d'évènements section lists APIs that can
read from pipes and watch file descriptors without blocking the event
loop. In addition, asyncio's Subprocess APIs provide a way to start a
process and communicate with it from the event loop. Lastly, the
aforementioned "loop.run_in_executor()" method can also be used with a
"concurrent.futures.ProcessPoolExecutor" to execute code in a
different process.


Exécution de code bloquant
==========================

Du code bloquant sur des opérations de calcul (*CPU-bound*) ne devrait
pas être appelé directement. Par exemple, si une fonction effectue des
calculs utilisant le CPU intensivement pendant une seconde, toutes les
tâches *asyncio* concurrentes et les opérations d'entrées-sorties
seront bloquées pour une seconde.

Un exécuteur peut être utilisé pour traiter une tâche dans un fil
d'exécution ou un processus différent, afin d'éviter de bloquer le fil
d'exécution système dans lequel se trouve la boucle d’évènements. Voir
"loop.run_in_executor()" pour plus de détails.


Journalisation
==============

*Asyncio* utilise le module "logging". Toutes les opérations de
journalisation sont effectuées via l'enregistreur (*logger*)
""asyncio"".

Le niveau de journalisation par défaut est "logging.INFO" mais peut
être ajusté facilement :

   logging.getLogger("asyncio").setLevel(logging.WARNING)

Network logging can block the event loop. It is recommended to use a
separate thread for handling logs or use non-blocking IO. For example,
see Utilisation de gestionnaires bloquants.


Détection des coroutines jamais attendues
=========================================

Lorsqu'une fonction coroutine est appelée mais qu'elle n'est pas
attendue (p. ex.  "coro()" au lieu de "await coro()") ou si la
coroutine n'est pas planifiée avec "asyncio.create_task()", *asyncio*
émet un "RuntimeWarning" :

   import asyncio

   async def test():
       print("never scheduled")

   async def main():
       test()

   asyncio.run(main())

Sortie :

   test.py:7: RuntimeWarning: coroutine 'test' was never awaited
     test()

Affichage en mode débogage :

   test.py:7: RuntimeWarning: coroutine 'test' was never awaited
   Coroutine created at (most recent call last)
     File "../t.py", line 9, in <module>
       asyncio.run(main(), debug=True)

     < .. >

     File "../t.py", line 7, in main
       test()
     test()

La façon habituelle de régler ce problème est d'attendre (*await*) la
coroutine ou bien d'appeler la fonction "asyncio.create_task()" :

   async def main():
       await test()


Détection des exceptions jamais récupérées
==========================================

Si la méthode "Future.set_exception()" est appelée mais que l'objet
*Future* n'est pas attendu, l'exception n'est pas propagée au code
utilisateur. Dans ce cas, *asyncio* écrit un message dans le journal
lorsque l'objet *Future* est récupéré par le ramasse-miette.

Exemple d'une exception non-gérée :

   import asyncio

   async def bug():
       raise Exception("not consumed")

   async def main():
       asyncio.create_task(bug())

   asyncio.run(main())

Sortie :

   Task exception was never retrieved
   future: <Task finished coro=<bug() done, defined at test.py:3>
     exception=Exception('not consumed')>

   Traceback (most recent call last):
     File "test.py", line 4, in bug
       raise Exception("not consumed")
   Exception: not consumed

Activez le mode débogage pour récupérer la trace d'appels indiquant où
la tâche a été créée :

   asyncio.run(main(), debug=True)

Affichage en mode débogage :

   Task exception was never retrieved
   future: <Task finished coro=<bug() done, defined at test.py:3>
       exception=Exception('not consumed') created at asyncio/tasks.py:321>

   source_traceback: Object created at (most recent call last):
     File "../t.py", line 9, in <module>
       asyncio.run(main(), debug=True)

   < .. >

   Traceback (most recent call last):
     File "../t.py", line 4, in bug
       raise Exception("not consumed")
   Exception: not consumed
