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

Lindolfo "Lorn" Rodrigues lorn.br at gmail.com
Tue Sep 8 07:31:20 PDT 2009


 "não é o suficiente para a demanda atual. Toda a
escalabilidade de Erlang é baseada em procs."

Comparar os "processos"  de Erlang, com processos do S.O eh covardia :P sao
diferentes.
Eu tambem soh usei fork no perl, e nao tenho muito interesse com thread no
Perl.

2009/9/8 Otávio Fernandes <otaviof em gmail.com>

> > 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<http://search.cpan.org/%7Erybskej/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/
> _______________________________________________
> SaoPaulo-pm mailing list
> SaoPaulo-pm em pm.org
> http://mail.pm.org/mailman/listinfo/saopaulo-pm
>



-- 
--Lindolfo "Lorn" Rodrigues
www.slackwarezine.com.br
http://lornlab.org
http://sao-paulo.pm.org
use Catalyst;
-------------- Pr?xima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20090908/4282e5f6/attachment-0001.html>


More information about the SaoPaulo-pm mailing list