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

[Otávio Fernandes]

> Bom, o fork() é emulado em Windows mas funciona da mesma maneira. Eu
> passei a utilizar threads porque eu acho que ficar cuidando de fork()s
> é uma bagunça.

Cuidar de forks/threads é uma bagunça quando você o faz desta maneira,
é uma dificuldade inerente ao paralelismo, correto?. Depende de você.

> Nas vezes em que eu precisava de usar processos por falta de suporte à
> threads pelo Perl do sistema, pelo menos eu tentava utilizar o módulo
> forks:
>
>  http://search.cpan.org/~rybskej/forks-0.33/lib/forks.pm
>
> Esse módulo é bastante interessante, pois suporta a mesma API de
> threads, mas utilizando processos.
> Algumas coisas são mais ineficientes, como varíaveis compartilhadas,
> mas funciona.
>
> Mas ficar insistindo em múltiplos processos hoje em dia é como
> insistir no protecionismo da indústria automobilística brasileira. Tem
> muita gente que acha certo, mas na verdade é um retrocesso.

Desculpe Nilson, mas este é um grande equivoco, seguido de generalismo
barato. Tanto threads como processos tem seu lugar ao sol.

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.

O que é um retrocesso para você?

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.

Lembre-se que nós estamos discutindo Perl aqui na lista, é até
irónico. Veja para o mercado qual a opinião deles sobre. Porem, vamos
analisar o mesmo fato daqui a 5 ou 10 anos.

> Em alguns anos, até mesmo os threads serão heavy-weight demais, pois a
> tendência é aumentar o número de unidades de execução, diminuindo a
> capacidade individual. O scheduler consegue fazer decisões bem
> melhores para threads que pra processos, até porque a troca de
> contexto entre threads é mais barata se comparado a uma troca de
> contextos completa.

Para estes casos, existe a solução correta, a solução errada e todas
as outras. Com a decisão correta do seu scheduler, quanto de
desempenho a mais você vai obter? Performance de uma aplicação é um
assunto complexo, seu software não precisa ser estupidamente rápido,
só precisar ser rápido o suficiente. Se você organizá-lo de forma
coerente, vai conseguir ter um ótimo resultado com processos, sem
dúvida. No entanto, a troca de contexto é realmente um ponto fraco de
processos.

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.

$ perldoc perlthrtut
(...)
What kind of threads are Perl threads?
    If you have experience with other thread implementations, you might find
    that things aren't quite what you expect. It's very important to
    remember when dealing with Perl threads that *Perl Threads Are Not X
    Threads* for all values of X. They aren't POSIX threads, or DecThreads,
    or Java's Green threads, or Win32 threads. There are similarities, and
    the broad concepts are the same, but if you start looking for
    implementation details you're going to be either disappointed or
    confused. Possibly both.

    This is not to say that Perl threads are completely different from
    everything that's ever come before -- they're not. Perl's threading
    model owes a lot to other thread models, especially POSIX. Just as Perl
    is not C, though, Perl threads are not POSIX threads. So if you find
    yourself looking for mutexes, or thread priorities, it's time to step
    back a bit and think about what you want to do and how Perl can do it.

    However, it is important to remember that Perl threads cannot magically
    do things unless your operating system's threads allow it. So if your
    system blocks the entire process on "sleep()", Perl usually will, as
    well.
(...)

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.

um abraço,

-- 
Otávio Fernandes <otaviof at gmail.com>
http://otaviof.blogspot.com/