Quand choisiriez-vous les threads, les processus ou asyncio ?

Utilisez asyncio pour des entrées/sorties à fort volume où vous voulez des milliers d'attentes concurrentes dans un seul thread, les threads pour du travail d'entrées/sorties dont seules des bibliothèques bloquantes existent, et les processus pour du travail limité par le CPU qui a besoin de vrais cœurs. Les questions décisives sont de savoir si le travail attend ou s'il calcule, et si les bibliothèques dont vous dépendez offrent une interface asynchrone.

Ma première question est toujours de savoir si le travail attend ou s'il calcule, parce que la réponse choisit l'outil. Attendre sur le réseau ou sur le disque, c'est asyncio si les bibliothèques clientes le permettent, puisqu'une boucle d'événements tient sans broncher dix mille sockets ouverts sur un cœur et que la mémoire par tâche est minuscule. Si le seul pilote disponible est bloquant, je prends un pool de threads, parce qu'un thread garé dans une lecture de socket relâche le verrou et ne coûte presque rien. Calculer, c'est les processus, ou passer par une bibliothèque native qui relâche elle-même le verrou. Sur un service sur lequel j'ai travaillé, nous avions les deux dans un même chemin de requête : un handler asynchrone qui interrogeait six API internes avec gather, et un appel run_in_executor qui enveloppait un vieux SDK bloquant que nous ne pouvions pas remplacer. Cette combinaison vaut la peine d'être citée en entretien parce que la plupart des vrais systèmes sont mixtes. L'erreur que je guette, c'est quelqu'un qui met une lourde transformation pandas dans une coroutine, parce que la boucle cesse alors de servir tout le reste pendant qu'elle tourne.