Despacho Python: Tornando o GIL opcional

O Conselho de Direção fez um grande anúncio sobre o futuro do Python. Nomeadamente, eles decidiram tornar o Global Interpreter Lock (GIL) opcional no CPython e eventualmente remover o GIL por completo.

Esta é uma decisão enorme que irá alterar fundamentalmente o Python.

Por isso, neste post, vou falar sobre o que é a GIL, as suas vantagens e desvantagens e o que o futuro nos reserva.

O GIL

Vou analisar o Global Interpreter Lock uma palavra de cada vez, em ordem inversa, começando por fechadura e depois intérprete e finalmente, global.

Um bloqueio é um mecanismo que permite que apenas uma thread seja executada de cada vez. Assim, quando uma thread obtém o bloqueio, ela ganha acesso exclusivo ao interpretador Python.

Um interpretador é o programa para executar o código Python.

A palavra "global" aqui se refere ao escopo do bloqueio do interpretador. Como o bloqueio do interpretador é global, ele garante que apenas uma thread executa o código Python de cada vez dentro de um único processo.

Portanto, o GIL é um mecanismo que impede que várias threads sejam executadas ao mesmo tempo através do interpretador. Mas por que é que queríamos isso?

Vantagens

A principal vantagem do GIL é que torna as coisas mais fáceis. Gerir a memória é mais fácil, gerir as threads é mais fácil e criar módulos é mais fácil.

Sem o GIL, você pode rapidamente ter problemas com multithreading. Se você não colocar os bloqueios locais apropriados para cada thread, você pode acabar travando o Python ou corrompendo alguma outra memória no computador.

E se não estiver a fazer multithreading, então o GIL é super útil, porque mantém tudo a funcionar sem problemas.

Assim, o GIL mantém as coisas simples e seguras.

Então, porque é que não havia de querer isso?

Desvantagens

A troca aqui é a facilidade pela rapidez.

Ao impedir o multithreading, o GIL torna o CPython mais lento e com menos desempenho do que algumas outras linguagens (como C++, Go e Rust).

Especialmente com a explosão da IA nos últimos meses, o GIL está a tornar-se cada vez mais um problema na execução de programas de forma rápida e eficiente.

O futuro da GIL

Assim, agora que o Conselho de Direção anunciou que aceitou a Python Enhancement Proposal (PEP) 703, escrito por Sam GrossEstamos a entrar em águas desconhecidas.

Inúmeras extensões foram escritas com o GIL em mente. Todos os padrões estabelecidos com o CPython dependem do GIL. Todos constroem em CPython com a GIL no centro de seus programas (intencionalmente ou não).

Assim, o Conselho de Direção está, numa primeira fase, a tornar o GIL facultativo, mas, a longo prazo, tenciona suprimi-lo completamente.

Tal como foi dito no post, "Não queremos criar uma divisão permanente entre compilações com-GIL e sem-GIL (e módulos de extensão)".

Isto vai transformar absolutamente a Python e, talvez o mais interessante, de formas que ainda ninguém conhece. Brett Cannon, numa sondagem à equipa de programadores principaisescreveu que "fazer Python free-threaded... tem um monte de incógnitas. Nós não sabemos quanto código implicitamente depende do GIL, ou não é seguro para threads de maneiras sutis que são mascaradas pelo GIL."

O GIL está a desaparecer - o que é que vai levar com ele?

E, mais importante ainda, como será o novo CPython?