Pouvez-vous expliquer ce qu'est le GIL et ce qu'il protège réellement ?

Le Global Interpreter Lock est un mutex de CPython qui n'autorise qu'un seul thread à exécuter du bytecode Python à la fois, ce qui protège l'état de l'interpréteur comme les compteurs de références et les structures internes des objets. Autrement dit, les threads ne vous donnent aucun gain de parallélisme sur du code Python limité par le CPU, mais ils restent utiles pour les entrées/sorties, parce que le verrou est relâché pendant les appels bloquants et le travail des extensions C.

Le GIL est un verrou unique dans CPython qui garantit qu'un seul thread exécute du bytecode Python à un instant donné. Il existe parce que le comptage de références n'est pas sûr en environnement multithread, et parce qu'un verrou par objet serait plus lent dans le cas monothread où vit la majorité du code. Concrètement, les threads sont excellents pour attendre et inutiles pour calculer. Sur un pipeline de données sur lequel j'ai travaillé, une étape allait chercher environ huit cents URL, et passer d'une boucle séquentielle à un pool de threads l'a fait tomber d'environ neuf minutes à moins d'une, parce que chaque worker passe sa vie bloqué sur un socket et relâche le verrou pendant qu'il attend. L'étape de parsing juste à côté n'y a rien gagné du tout, donc nous l'avons poussée dans un pool de processus. Numpy et d'autres extensions C relâchent aussi le verrou pendant leurs appels natifs longs, ce qui explique pourquoi les gros calculs matriciels peuvent sembler parallèles même dans des threads. Quand on me dit que Python ne sait pas faire de concurrence, je demande en général de quel type on parle.