gh-116167: Permitir desativar o GIL

Escopo da Mudança / Status Atual

  • A mudança vem do trabalho para tornar o GIL opcional (PEP 703).
  • A PR atual exige compilar o CPython com uma flag especial e, em seguida, desativar o GIL via um alternador em tempo de execução.
  • Isto é explicitamente uma etapa inicial, em fase de pesquisa: a intenção é funcionar de forma confiável apenas para programas sem threads.
  • Os testes do asyncio falham com o GIL desativado; alguns programas simples com threads “parecem” funcionar, mas não têm segurança garantida.

Desempenho em Thread Única vs Multi-Thread

  • Remover o GIL permite paralelismo real em múltiplos núcleos em Python multi-threaded, útil para cargas de trabalho com muitas threads (por exemplo, ML, pesquisa).
  • Para código com thread única, vários comentários observam uma penalidade de desempenho devido a locking extra; a PEP 703 cita uma desaceleração de 5–15%.
  • Alguns esperam que mais otimizações possam reduzir, ao longo do tempo, o overhead em builds nogil de thread única.

Asyncio, Threads e Compatibilidade

  • Vários comentários esclarecem: I/O assíncrono e threads do SO são distintas; as falhas atuais estão sobretudo nos testes do asyncio que misturam threads e corrotinas.
  • Há confusão no tópico sobre se “qualquer código com threads” quebra; o consenso é: muitos padrões existentes com threads, especialmente os que envolvem objetos compartilhados, são inseguros nesta versão.

Alternativas às Threads Hoje

  • multiprocessing é amplamente citado como alternativa para tarefas CPU-bound, mas:
    • No Windows e no macOS, a ausência de fork / uso de spawn torna isso lento e desajeitado.
    • Grandes footprints de memória e estruturas de dados compartilhadas complexas tornam o paralelismo baseado em processos doloroso.
  • Bibliotecas como Ray ajudam com multi-processo e memória compartilhada, mas têm suas próprias limitações (por exemplo, objetos imutáveis focados em arrays).

Impacto no Ecossistema e em Extensões C

  • A maioria das extensões nativas (C/C++) depende implicitamente do GIL para segurança em threads (globais, mutações não sincronizadas em listas etc.).
  • O plano é: se uma extensão depender do GIL, ela o manterá ativado; no longo prazo, as extensões precisarão ser atualizadas para serem seguras sem GIL ou usar GIL explicitamente.

Python vs Outras Linguagens e Tipagem

  • Vários comentaristas argumentam que, se você quer “Python + tipos + concorrência” hoje, Go, Rust, C#, Kotlin, Julia, Nim ou linguagens BEAM podem ser melhores opções.
  • Outros contrapõem que o ecossistema do Python (NumPy, PyTorch, ferramentas de ML/DS) domina, e o nogil junto com verificadores de tipos modernos (por exemplo, mypy, pyright) torna o Python competitivo para muitos casos de uso.
  • O debate continua sobre a velocidade e o modelo de tipagem do Python vs linguagens “modernas”, com o reconhecimento de que o Python continuará mais lento, mas ainda pode melhorar significativamente.