¿El Python GIL es realmente por intérprete?

Question

A menudo veo gente hablando de que el GIL es por intérprete de Python (incluso aquí en stackoverflow).

Pero lo que veo en el código fuente parece ser que el GIL es una variable global y, por lo tanto, hay un GIL para todos los intérpretes en cada proceso de python. Sé que lo hicieron porque no hay un objeto interpretado como lua o TCL, simplemente no fue diseñado al principio. Y el almacenamiento local de subprocesos parece no ser portátil para que lo usen los chicos de Python.

¿Es esto correcto? Eché un vistazo a la versión 2.4 que estoy usando en un proyecto aquí.

¿Ha cambiado esto en versiones posteriores, especialmente en 3.0?

Answer 1

El GIL es de hecho por proceso, no por intérprete. Esto no se modifica en 3.x.

Answer 2

Creo que es cierto (al menos a partir de Python 2.6) que cada proceso puede tener como máximo un intérprete CPython incrustado (otros tiempos de ejecución pueden tener diferentes restricciones). No estoy seguro de si esto es un problema con el GIL per se, pero es probable debido al estado global, o para protegerse del estado global conflictivo en los módulos de C de terceros. Desde el CPython API Docs:

[Py ___ Initialize()] es un no-op cuando se le llama por segunda vez (sin llamar Py_Finalize() primero). No hay valor de retorno; es un error fatal si la inicialización falla.

Puede que le interese el proyecto Unladen Swallow, cuyo objetivo final es eliminar completamente el GIL de CPython. Otros tiempos de ejecución de Python no tienen el GIL en absoluto, como (creo) Stackless Python, y ciertamente Jython.

También tenga en cuenta que el GIL es still present in CPython 3.x.

Answer 3

Quizás la confusión se produce porque la mayoría de las personas asume que Python tiene un intérprete por proceso. Recuerdo haber leído que el soporte para múltiples intérpretes a través de la API C no se había probado y casi nunca se había utilizado. (Y cuando lo probé, no funcionó correctamente.)