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 fonctionasyncio.run();en appelant la méthode
loop.set_debug().
En plus d'activer le mode débogage, vous pouvez également :
setting the log level of the asyncio logger to
logging.DEBUG, for example the following snippet of code can be run at startup of the application:logging.basicConfig(level=logging.DEBUG)
configurer le module
warningsafin d'afficher les avertissements de typeResourceWarning; vous pouvez faire cela en utilisant l'option-Wdefaultsur la ligne de commande.
Lorsque le mode débogage est activé :
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 ;
les fonctions de rappel prenant plus de 100 ms sont journalisées ; l'attribut
loop.slow_callback_durationpeut être utilisé pour changer la limite (en secondes) après laquelle une fonction de rappel est considérée comme « lente ».
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()
To handle signals the event loop must be run in the main thread.
The loop.run_in_executor() method can be used with a
concurrent.futures.ThreadPoolExecutor or
InterpreterPoolExecutor to execute
blocking code in a different OS thread without blocking the OS thread
that the event loop runs in.
Il n'y a actuellement aucune façon de planifier des coroutines ou des rappels directement depuis un autre processus (comme, par exemple, un processus démarré avec multiprocessing). La section Méthodes de la boucle d'évènements liste les API pouvant lire les tubes (pipes) et surveiller les descripteurs de fichiers sans bloquer la boucle d'évènements. De plus, les API Subprocess d'asyncio fournissent un moyen de démarrer un processus et de communiquer avec lui depuis la boucle d'évènements. Enfin, la méthode loop.run_in_executor() susmentionnée peut également être utilisée avec concurrent.futures.ProcessPoolExecutor pour exécuter du code dans un processus différent.
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.
An executor can be used to run a task in a different thread,
including in a different interpreter, or even in
a different process to avoid blocking the OS thread with the
event loop. See the loop.run_in_executor() method for more
details.
Journalisation¶
Asyncio utilise le module logging. Toutes les opérations de journalisation sont effectuées via l'enregistreur (logger) "asyncio".
The default log level is logging.INFO, which can be easily
adjusted:
logging.getLogger("asyncio").setLevel(logging.WARNING)
La journalisation réseau peut bloquer la boucle d'événements. Il est recommandé d'utiliser un fil d'exécution séparé pour gérer les journaux ou d'utiliser des entrées-sorties non bloquantes. Par exemple, voir 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
Asynchronous generators best practices¶
Writing correct and efficient asyncio code requires awareness of certain pitfalls. This section outlines essential best practices that can save you hours of debugging.
Close asynchronous generators explicitly¶
It is recommended to manually close the
asynchronous generator. If a generator
exits early - for example, due to an exception raised in the body of
an async for loop - its asynchronous cleanup code may run in an
unexpected context. This can occur after the tasks it depends on have completed,
or during the event loop shutdown when the async-generator's garbage collection
hook is called.
To avoid this, explicitly close the generator by calling its
aclose() method, or use the contextlib.aclosing()
context manager:
import asyncio import contextlib async def gen(): yield 1 yield 2 async def func(): async with contextlib.aclosing(gen()) as g: async for x in g: break # Don't iterate until the end asyncio.run(func())
As noted above, the cleanup code for these asynchronous generators is deferred. The following example demonstrates that the finalization of an asynchronous generator can occur in an unexpected order:
import asyncio work_done = False async def cursor(): try: yield 1 finally: assert work_done async def rows(): global work_done try: yield 2 finally: await asyncio.sleep(0.1) # immitate some async work work_done = True async def main(): async for c in cursor(): async for r in rows(): break break asyncio.run(main())
For this example, we get the following output:
unhandled exception during asyncio.run() shutdown task: <Task finished name='Task-3' coro=<<async_generator_athrow without __name__>()> exception=AssertionError()> Traceback (most recent call last): File "example.py", line 6, in cursor yield 1 asyncio.exceptions.CancelledError During handling of the above exception, another exception occurred: Traceback (most recent call last): File "example.py", line 8, in cursor assert work_done ^^^^^^^^^ AssertionError
The cursor() asynchronous generator was finalized before the rows
generator - an unexpected behavior.
The example can be fixed by explicitly closing the
cursor and rows async-generators:
async def main(): async with contextlib.aclosing(cursor()) as cursor_gen: async for c in cursor_gen: async with contextlib.aclosing(rows()) as rows_gen: async for r in rows_gen: break break
Create asynchronous generators only when the event loop is running¶
It is recommended to create asynchronous generators only after the event loop has been created.
To ensure that asynchronous generators close reliably, the event loop uses the
sys.set_asyncgen_hooks() function to register callback functions. These
callbacks update the list of running asynchronous generators to keep it in a
consistent state.
When the loop.shutdown_asyncgens()
function is called, the running generators are stopped gracefully and the
list is cleared.
The asynchronous generator invokes the corresponding system hook during its first iteration. At the same time, the generator records that the hook has been called and does not call it again.
Therefore, if iteration begins before the event loop is created, the event loop will not be able to add the generator to its list of active generators because the hooks are set after the generator attempts to call them. Consequently, the event loop will not be able to terminate the generator if necessary.
Consider the following example:
import asyncio async def agenfn(): try: yield 10 finally: await asyncio.sleep(0) with asyncio.Runner() as runner: agen = agenfn() print(runner.run(anext(agen))) del agen
Sortie :
10 Exception ignored while closing generator <async_generator object agenfn at 0x000002F71CD10D70>: Traceback (most recent call last): File "example.py", line 13, in <module> del agen ^^^^ RuntimeError: async generator ignored GeneratorExit
This example can be fixed as follows:
import asyncio async def agenfn(): try: yield 10 finally: await asyncio.sleep(0) async def main(): agen = agenfn() print(await anext(agen)) del agen asyncio.run(main())
Avoid concurrent iteration and closure of the same generator¶
Async generators may be reentered while another
__anext__() / athrow() / aclose() call is in
progress. This may lead to an inconsistent state of the async generator and can
cause errors.
Let's consider the following example:
import asyncio async def consumer(): for idx in range(100): await asyncio.sleep(0) message = yield idx print('received', message) async def amain(): agenerator = consumer() await agenerator.asend(None) fa = asyncio.create_task(agenerator.asend('A')) fb = asyncio.create_task(agenerator.asend('B')) await fa await fb asyncio.run(amain())
Sortie :
received A Traceback (most recent call last): File "test.py", line 38, in <module> asyncio.run(amain()) ~~~~~~~~~~~^^^^^^^^^ File "Lib/asyncio/runners.py", line 204, in run return runner.run(main) ~~~~~~~~~~^^^^^^ File "Lib/asyncio/runners.py", line 127, in run return self._loop.run_until_complete(task) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^ File "Lib/asyncio/base_events.py", line 719, in run_until_complete return future.result() ~~~~~~~~~~~~~^^ File "test.py", line 36, in amain await fb RuntimeError: anext(): asynchronous generator is already running
Therefore, it is recommended to avoid using asynchronous generators in parallel tasks or across multiple event loops.