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
;Using the
-X
dev
Python command line option.en passant
debug=True
à la fonctionasyncio.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 typeResourceWarning
; 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()
etloop.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 ;
Callbacks taking longer than 100ms are logged. The
loop.slow_callback_duration
attribute can be used to set the minimum execution duration in seconds that is considered "slow".
Concourance et multithreading¶
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 Event Loop Methods
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)
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