# 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 :

- 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 `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é :

- 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 « 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.

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.

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.

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"`.

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