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 despawntorna isso lento e desajeitado. - Grandes footprints de memória e estruturas de dados compartilhadas complexas tornam o paralelismo baseado em processos doloroso.
- No Windows e no macOS, a ausência de
- 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.