Python Dispatch: Hacer opcional el GIL
El Consejo Director ha hecho un gran anuncio sobre el futuro de Python. En concreto, han decidido hacer que el Bloqueo Global del Intérprete (GIL) sea opcional en CPython y, con el tiempo, eliminar el GIL por completo.
Se trata de una gran decisión que alterará fundamentalmente a Python.
Por ello, en este post repasaré qué es el GIL, sus ventajas e inconvenientes y qué nos depara el futuro.
El GIL
Permítanme repasar el Bloqueo Global de Intérpretes palabra por palabra en orden inverso, empezando por cierre y luego intérprete y finalmente, global.
Un bloqueo es un mecanismo que sólo permite la ejecución de un hilo a la vez. Así que cuando un hilo se hace con el bloqueo, obtiene acceso exclusivo al intérprete de Python.
En el intérprete es el programa que ejecuta el código Python.
La palabra "global" aquí se refiere al alcance del bloqueo del intérprete. Dado que el bloqueo del intérprete es global, garantiza que sólo un hilo ejecute código Python a la vez dentro de un único proceso.
Así que el GIL es un mecanismo que impide que varios hilos se ejecuten al mismo tiempo a través del intérprete. Pero, ¿por qué querrías eso?
Ventajas
La principal ventaja del GIL es que facilita las cosas. La gestión de la memoria es más fácil, la gestión de los hilos es más fácil y la creación de módulos es más fácil.
Sin el GIL, puedes encontrarte rápidamente con problemas de multihilo. Si no colocas los bloqueos locales apropiados para cada hilo, puedes acabar bloqueando Python o corrompiendo alguna otra memoria del ordenador.
Y si no eres multihilo, entonces el GIL es súper útil, porque mantiene todo funcionando sin problemas.
Así que el GIL mantiene las cosas sencillas y seguras.
Entonces, ¿por qué no querrías eso?
Desventajas
En este caso, el compromiso es facilidad por rapidez.
Al impedir el multihilo, el GIL hace que CPython sea más lento y tenga menos rendimiento que otros lenguajes (como C++, Go y Rust).
Especialmente con la explosión de la IA en los últimos meses, el GIL se está convirtiendo cada vez más en un problema para ejecutar programas de forma rápida y eficiente.
El futuro del GIL
Así que ahora que el Consejo de Dirección ha anunciado que ha aceptado la Propuesta de mejora de Python (PEP) 703, escrita por Sam Grossestamos entrando en aguas desconocidas.
Se han escrito innumerables extensiones teniendo en cuenta el GIL. Todos los estándares establecidos con CPython dependen del GIL. Todo el mundo construye en CPython con el GIL en el centro de sus programas (intencionadamente o no).
Por ello, el Consejo de Dirección ha decidido que, en un principio, el GIL sea optativo, pero a largo plazo tiene previsto eliminarlo por completo.
Como dicen en el post: "No queremos crear una división permanente entre builds con y sin GIL (y módulos de ampliación)".
Esto transformará absolutamente Python y, quizá lo más interesante, de formas que nadie conoce todavía. Brett Cannon, en una encuesta al equipo central de desarrolladoresescribió que "hacer Python libre de hilos... tiene muchas incógnitas. No sabemos cuánto código depende implícitamente del GIL, o es inseguro para los hilos de formas sutiles que están enmascaradas por el GIL".
El GIL desaparece: ¿qué se llevará consigo?
Y, lo que es más importante, ¿cómo será el nuevo CPython?