[SP-pm] WWW::Curl::Multi

Nilson Santos Figueiredo Jr. acid06 at gmail.com
Tue Sep 8 07:46:30 PDT 2009


2009/9/8 Otávio Fernandes <otaviof at gmail.com>:
> Vamos analisar os modelos de escalabilidade de SOs unix-like. Quando
> utilizamos processos, podemos dividir vários deles em servidores
> diferentes para balancear carga, e utilizar uma comunicação padrão
> (sockets, por exemplo). Ou seja, com processos podemos escalar
> horizontalmente, ao menos temos ferramentas para isso. Porem, nada nos
> impede de, se for necessário, utilizar threads dentro destas unidades.

No caso em que é necessário realizar balanceamento de carga entre
servidores, a utilização de processos é mais apropriada porque, bem,
não existe outra maneira. ;-)

Mas, dependendo da tarefa, uma camada de abstração como o TheSchwartz
ou o Gearman vai ser melhor do que fork()ar seus processos na mão e
cuidar de toda a comunicação.

> Há 10 anos atrás Erlang era uma linguagem ultrapassada e com
> pouquíssimo uso comercial, porque nós tomávamos como verdade a Lei de
> Moore (http://pt.wikipedia.org/wiki/Lei_de_Moore). Durante um certo
> tempo este modelo funcionou, porem, com o crescimento da internet e a
> necessidade de Escalabilidade, a Lei de Moorre, além de não ser mais
> verdade, não é o suficiente para a demanda atual. Toda a
> escalabilidade de Erlang é baseada em procs.

Na verdade, acho que você não deve ter lido o suficiente sobre Erlang.
A linguagem não utiliza processos (ou threads) do OS para implementar
o seu conceito de "processos". A sua implementação é similar aos
antigos "green threads" de Java, ou seja, é uma simulação de
multi-tasking dentro de um processo só, só que sem shared-state entre
os fluxos de execução (por isso chamam de processos e não threads).
Aliás, Java também não utiliza mais os "green threads" agora utiliza
threads do OS mesmo.

> Perl não tem suporte a Green Threads e, particularmente, eu não me
> sinto a vontade ao usar memória compartilhada para escrita, é no
> mínimo arriscado.

Não é arriscado se você utiliza corretamente: somente para estruturas
de controle. Se você utilizar pra todo lado, na verdade, além de
spaghetti code, vai ter problemas de performance, pois como o modelo
de variáveis compartilhadas em Perl é "simulado" (são múltiplas cópias
mantidas em sincronia), existe um overhead maior que com lightweight
threads.

Pra todos os efeitos, threads em Perl são bem similares a processos,
com menos overhead, sem CoW e com uma melhor API *nativa* para
gerenciamento dos fluxos de execução (mas você pode usar o forks pra
ter a mesma API com processos).

> Na minha opinião, quando existe um bom planejamento e necessidade
> específica, threads são uma boa escolha. Porem, o problema é usar
> threads com Perl! Fica bem claro o fato de não ter um bom suporte e
> também de não ser o foco da linguagem. Existem ferramentas melhores
> para a demanda de threads em outras linguagens de programação.

Eu já utilizei muito mais vezes forked processes que threads.

O intuito dessas minhas mensagens não é tentar convencer todo mundo a
usar threads em todos os casos: nem tudo é um prego quando você tem um
martelo.

O objetivo é tentar desmanchar um pouco do mito que "threads em Perl
não prestam". Esse mindset é danoso à linguagem por questões técnicas
(menos future-proof) e até mesmo, inclusive, por uma estratégia de
marketing da linguagem (pra quem se importa com isso).

-Nilson Santos F. Jr.


More information about the SaoPaulo-pm mailing list