Mudanças entre as edições de "Python Concorrente"
| Linha 5: | Linha 5: | ||
| − | + | == Concorrência em Python == |
|
| − | Ao contrário de Go |
+ | Ao contrário de Go, Python não foi originalmente projetada com foco em programação concorrente. O modo tradicional de programar concorrência em Python -- threads -- é limitado no interpretador padrão (CPython) por uma trava global (a GIL) que impede a execução paralela de threads escritas em Python. Isso significa que threads em Python são úteis apenas em aplicações ''I/O bound'' -- onde o gargalo está no I/O, como é o caso de aplicações na Internet. |
| + | === Porque a GIL existe === |
||
| + | |||
| + | A GIL foi criada para simplificar o código em C do interpretador e facilitar a intergração de bibliotecas externas em C que não são thread-safe. Uma razão do sucesso de Python é a imensa varidedade de bibliotecas externas disponíveis, e sem GIL seria muito mais complicado e caro fazer essas integrações. O interpretador padrão de Ruby (MRI) tem também uma ''Global VM Lock'', pelos mesmos motivos. As implementações de Python e Ruby em Java (Jython e JRuby) não têm uma trava global. |
||
| + | |||
| + | == Como fazer ncorrência sem paralelismo == |
||
| + | |||
| + | O segredo é não deixar seu programa jamais esperar por uma resposta na rede. Isso pode ser feito de duas formas: |
||
| + | |||
| + | * Com threads, pois as funções de IO da biblioteca padrão de Python liberam a GIL enquanto esperam, permitindo que outra thread avance. Para isso se usa o [https://docs.python.org/3/library/threading.html módulo threading]. |
||
| + | |||
| + | * Com programação orientada a eventos, onde cada função de IO aceita uma função de callback como argumento, e este callback é invocado quando o dispositivo de IO está pronto para enviar/receber dados, ou já enviou/recebeu dados. Para isso se usa o módulo [https://docs.python.org/3/library/asyncio.html asyncio]. |
||
| + | |||
| + | As duas formas podem ser chamadas de '''programação assíncrona''', porque as requisições e respostas podem acontecer fora de ordem. Por exemplo, se um programa usando threads ou <code>asyncio</code> iniciar várias requisições HTTP, as respostas não virão necessariamente mesma ordem, e serão tratadas na ordem em que chegarem. Em contraste, num programa síncrono com apenas uma thread, cada requisição fará o programa parar para aguardar a resposta correspondente, e uma nova requisição será feita somente quando a resposta anterior for recebida. |
||
| + | |||
| + | Porém na prática o termo '''programação assíncrona''' é aplicado mais frequentemente só para a programação orientada a eventos. |
||
=== Usando threads apesar da GIL === |
=== Usando threads apesar da GIL === |
||
Edição das 14h59min de 16 de janeiro de 2015
Concurrency is about dealing with lots of things at once. Parallelism is about doing lots of things at once.
Rob Pike, co-inventor da linguagem Go -- Concurrency is not Parallelism (it's better)
Concorrência em Python
Ao contrário de Go, Python não foi originalmente projetada com foco em programação concorrente. O modo tradicional de programar concorrência em Python -- threads -- é limitado no interpretador padrão (CPython) por uma trava global (a GIL) que impede a execução paralela de threads escritas em Python. Isso significa que threads em Python são úteis apenas em aplicações I/O bound -- onde o gargalo está no I/O, como é o caso de aplicações na Internet.
Porque a GIL existe
A GIL foi criada para simplificar o código em C do interpretador e facilitar a intergração de bibliotecas externas em C que não são thread-safe. Uma razão do sucesso de Python é a imensa varidedade de bibliotecas externas disponíveis, e sem GIL seria muito mais complicado e caro fazer essas integrações. O interpretador padrão de Ruby (MRI) tem também uma Global VM Lock, pelos mesmos motivos. As implementações de Python e Ruby em Java (Jython e JRuby) não têm uma trava global.
Como fazer ncorrência sem paralelismo
O segredo é não deixar seu programa jamais esperar por uma resposta na rede. Isso pode ser feito de duas formas:
- Com threads, pois as funções de IO da biblioteca padrão de Python liberam a GIL enquanto esperam, permitindo que outra thread avance. Para isso se usa o módulo threading.
- Com programação orientada a eventos, onde cada função de IO aceita uma função de callback como argumento, e este callback é invocado quando o dispositivo de IO está pronto para enviar/receber dados, ou já enviou/recebeu dados. Para isso se usa o módulo asyncio.
As duas formas podem ser chamadas de programação assíncrona, porque as requisições e respostas podem acontecer fora de ordem. Por exemplo, se um programa usando threads ou asyncio iniciar várias requisições HTTP, as respostas não virão necessariamente mesma ordem, e serão tratadas na ordem em que chegarem. Em contraste, num programa síncrono com apenas uma thread, cada requisição fará o programa parar para aguardar a resposta correspondente, e uma nova requisição será feita somente quando a resposta anterior for recebida.
Porém na prática o termo programação assíncrona é aplicado mais frequentemente só para a programação orientada a eventos.
Usando threads apesar da GIL
A GIL impede qualquer paralelismo no código escrito em Python, mas as funcionalidades da plataforma (interpretador, bibliotecas, API do sistema operacional) não são necessariamente limitadas pela GIL. Todas as chamadas da biblioteca padrão de Python que fazem I/O de rede ou arquivos liberam a GIL. Portanto, em qualquer processamento onde o limitante é o I/O (I/O bound) o uso de threads em Python pode acelerar muito o processamento em relação a uma solução sequencial que vai passar a maior parte do tempo aguardando I/O. Mas para processamentos limitados pela CPU (CPU bound) usar threads em Python não ajuda e pode até atrapalhar. Claro que bibliotecas externas escritas em C