Le Python GIL est-il vraiment par interprète?

Question

Je vois souvent des gens dire que le GIL est par interpréteur Python (même ici sur stackoverflow).

Mais ce que je vois dans le code source semble être que le GIL est une variable globale et donc il y a un GIL pour tous les interprètes dans chaque processus python. Je sais qu'ils l'ont fait parce qu'il n'y a pas d'objet d'interprète circulant comme lua ou TCL, ce n'était tout simplement pas bien conçu au début. Et le stockage local des threads ne semble pas portable pour les pythons.

Est-ce correct? J'ai regardé brièvement la version 2.4 que j'utilise dans un projet ici.

Avait-il changé dans les versions ultérieures, en particulier dans 3.0?

Answer 1

Le GIL est en effet par processus, pas par interprète. Ceci est inchangé dans 3.x.

Answer 2

Je crois qu'il est vrai (au moins à partir de Python 2.6) que chaque processus peut avoir au plus un interpréteur CPython intégré (d'autres temps d'exécution peuvent avoir des contraintes différentes). Je ne suis pas sûr que ce soit un problème avec le GIL en soi, mais c'est probablement dû à l'état global, ou pour protéger de l'état global conflictuel dans les modules C tiers. De l'CPython API Docs:

[___ Py initialize()] est un no-op lorsqu'il est appelé pour une deuxième fois (sans appeler Py_Finalize() en premier). Il n'y a pas de valeur de retour; c'est une erreur fatale si l'initialisation échoue.

Vous pourriez être intéressé par le projet Unladen Swallow, qui a pour but de supprimer complètement le GIL de CPython. D'autres runtimes Python n'ont pas du tout le GIL, comme (je crois) Stackless Python, et certainement Jython.

Notez également que le GIL est still present in CPython 3.x.

Answer 3

Peut-être que la confusion vient du fait que la plupart des gens pensent que Python a un interpréteur par processus. Je me souviens avoir lu que la prise en charge de plusieurs interprètes via l'API C était en grande partie non testée et rarement utilisée. (Et quand je l'ai essayé, ne fonctionnait pas correctement.)