Je vois souvent des gens parler que le gil est par interpréteur python (même ici sur Stackoverflow).
Mais ce que je vois dans le code source, il semble que le GIL est une variable globale et il existe donc un GIL pour tous les interprètes de chaque processus de Python. Je sais qu'ils l'ont fait parce qu'il n'y a pas d'objet interprète transmis comme Lua ou TCL, il n'était tout simplement pas bien conçu au début. Et enfiler le stockage local semble ne pas être portable pour les gars de Python à utiliser.
est-ce correct? J'ai eu un bref regard sur la version 2.4 que j'utilise dans un projet ici.
avait-il changé dans les versions ultérieures, en particulier en 3.0?
3 Réponses :
Je crois que c'est vrai (au moins comme de Python 2.6) que chaque processus peut avoir au plus un interprète CPPHON intégré (d'autres roulements peuvent avoir des contraintes différentes). Je ne sais pas si c'est un problème avec le gil en soi, mais il est probable qu'en raison de l'état mondial ou de protéger de l'état mondial contradictoire dans des modules de tiers. De CPPHON API Docs :
[py ___ initialize ()] est un non-op lorsque vous l'appelez une seconde fois (sans appeler py_finalize () d'abord). 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 SANDENDEN BIALLER , qui vise à éventuellement de Enlevez entièrement le gil de cpython. D'autres runtimes Python n'ont pas le gil du tout, comme (je crois) python sans empilement , et certainement < un href = "http://www.jython.org/" rel = "nofollow noreferrer"> Jython .
Notez également que le gil est toujours présent dans CPPHON 3.x .
Beaucoup de projets ont supprimé le Gil de CPPHON avant. L'hirondelle à vide n'est pas la première. Cependant, ils n'ont pas fonctionné aussi bien que la version Gil afin que personne ne les utilise.
En outre, Stackless ne supprime pas le gil. En fait, toute opération de blocage dans n'importe quel microthread sans empilement bloquera toute la demande.
Et Jython est si lent que c'est inutilisable aussi - à moins que vous ne l'utilisiez que pour un plugin de script dans un programme Java où la plupart des travaux sont effectués à Python.
Peut-être que la confusion vient parce que la plupart des gens supposent que Python a un interprète par processus. Je me souviens de lire que le soutien de plusieurs interprètes via l'API C était largement non testé et à peine jamais utilisé. (Et quand je l'ai donné un coup, je n'ai pas fonctionné correctement.)
Le gil est en effet per-processus, pas par interprète. Ceci est inchangé en 3.x.