"não é o suficiente para a demanda atual. Toda a<br>
escalabilidade de Erlang é baseada em procs."<br><br>Comparar os "processos" de Erlang, com processos do S.O eh covardia :P sao diferentes.<br>Eu tambem soh usei fork no perl, e nao tenho muito interesse com thread no Perl.<br>
<br><div class="gmail_quote">2009/9/8 Otávio Fernandes <span dir="ltr"><<a href="mailto:otaviof@gmail.com">otaviof@gmail.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">> Bom, o fork() é emulado em Windows mas funciona da mesma maneira. Eu<br>
> passei a utilizar threads porque eu acho que ficar cuidando de fork()s<br>
> é uma bagunça.<br>
<br>
</div>Cuidar de forks/threads é uma bagunça quando você o faz desta maneira,<br>
é uma dificuldade inerente ao paralelismo, correto?. Depende de você.<br>
<div class="im"><br>
> Nas vezes em que eu precisava de usar processos por falta de suporte à<br>
> threads pelo Perl do sistema, pelo menos eu tentava utilizar o módulo<br>
> forks:<br>
><br>
> <a href="http://search.cpan.org/%7Erybskej/forks-0.33/lib/forks.pm" target="_blank">http://search.cpan.org/~rybskej/forks-0.33/lib/forks.pm</a><br>
><br>
> Esse módulo é bastante interessante, pois suporta a mesma API de<br>
> threads, mas utilizando processos.<br>
> Algumas coisas são mais ineficientes, como varíaveis compartilhadas,<br>
> mas funciona.<br>
><br>
> Mas ficar insistindo em múltiplos processos hoje em dia é como<br>
> insistir no protecionismo da indústria automobilística brasileira. Tem<br>
> muita gente que acha certo, mas na verdade é um retrocesso.<br>
<br>
</div>Desculpe Nilson, mas este é um grande equivoco, seguido de generalismo<br>
barato. Tanto threads como processos tem seu lugar ao sol.<br>
<br>
Vamos analisar os modelos de escalabilidade de SOs unix-like. Quando<br>
utilizamos processos, podemos dividir vários deles em servidores<br>
diferentes para balancear carga, e utilizar uma comunicação padrão<br>
(sockets, por exemplo). Ou seja, com processos podemos escalar<br>
horizontalmente, ao menos temos ferramentas para isso. Porem, nada nos<br>
impede de, se for necessário, utilizar threads dentro destas unidades.<br>
<br>
O que é um retrocesso para você?<br>
<br>
Há 10 anos atrás Erlang era uma linguagem ultrapassada e com<br>
pouquíssimo uso comercial, porque nós tomávamos como verdade a Lei de<br>
Moore (<a href="http://pt.wikipedia.org/wiki/Lei_de_Moore" target="_blank">http://pt.wikipedia.org/wiki/Lei_de_Moore</a>). Durante um certo<br>
tempo este modelo funcionou, porem, com o crescimento da internet e a<br>
necessidade de Escalabilidade, a Lei de Moorre, além de não ser mais<br>
verdade, não é o suficiente para a demanda atual. Toda a<br>
escalabilidade de Erlang é baseada em procs.<br>
<br>
Lembre-se que nós estamos discutindo Perl aqui na lista, é até<br>
irónico. Veja para o mercado qual a opinião deles sobre. Porem, vamos<br>
analisar o mesmo fato daqui a 5 ou 10 anos.<br>
<div class="im"><br>
> Em alguns anos, até mesmo os threads serão heavy-weight demais, pois a<br>
> tendência é aumentar o número de unidades de execução, diminuindo a<br>
> capacidade individual. O scheduler consegue fazer decisões bem<br>
> melhores para threads que pra processos, até porque a troca de<br>
> contexto entre threads é mais barata se comparado a uma troca de<br>
> contextos completa.<br>
<br>
</div>Para estes casos, existe a solução correta, a solução errada e todas<br>
as outras. Com a decisão correta do seu scheduler, quanto de<br>
desempenho a mais você vai obter? Performance de uma aplicação é um<br>
assunto complexo, seu software não precisa ser estupidamente rápido,<br>
só precisar ser rápido o suficiente. Se você organizá-lo de forma<br>
coerente, vai conseguir ter um ótimo resultado com processos, sem<br>
dúvida. No entanto, a troca de contexto é realmente um ponto fraco de<br>
processos.<br>
<br>
Perl não tem suporte a Green Threads e, particularmente, eu não me<br>
sinto a vontade ao usar memória compartilhada para escrita, é no<br>
mínimo arriscado.<br>
<br>
$ perldoc perlthrtut<br>
(...)<br>
What kind of threads are Perl threads?<br>
If you have experience with other thread implementations, you might find<br>
that things aren't quite what you expect. It's very important to<br>
remember when dealing with Perl threads that *Perl Threads Are Not X<br>
Threads* for all values of X. They aren't POSIX threads, or DecThreads,<br>
or Java's Green threads, or Win32 threads. There are similarities, and<br>
the broad concepts are the same, but if you start looking for<br>
implementation details you're going to be either disappointed or<br>
confused. Possibly both.<br>
<br>
This is not to say that Perl threads are completely different from<br>
everything that's ever come before -- they're not. Perl's threading<br>
model owes a lot to other thread models, especially POSIX. Just as Perl<br>
is not C, though, Perl threads are not POSIX threads. So if you find<br>
yourself looking for mutexes, or thread priorities, it's time to step<br>
back a bit and think about what you want to do and how Perl can do it.<br>
<br>
However, it is important to remember that Perl threads cannot magically<br>
do things unless your operating system's threads allow it. So if your<br>
system blocks the entire process on "sleep()", Perl usually will, as<br>
well.<br>
(...)<br>
<br>
Na minha opinião, quando existe um bom planejamento e necessidade<br>
específica, threads são uma boa escolha. Porem, o problema é usar<br>
threads com Perl! Fica bem claro o fato de não ter um bom suporte e<br>
também de não ser o foco da linguagem. Existem ferramentas melhores<br>
para a demanda de threads em outras linguagens de programação.<br>
<div class="im"><br>
um abraço,<br>
<br>
--<br>
Otávio Fernandes <otaviof at <a href="http://gmail.com" target="_blank">gmail.com</a>><br>
<a href="http://otaviof.blogspot.com/" target="_blank">http://otaviof.blogspot.com/</a><br>
_______________________________________________<br>
</div><div><div></div><div class="h5">SaoPaulo-pm mailing list<br>
<a href="mailto:SaoPaulo-pm@pm.org">SaoPaulo-pm@pm.org</a><br>
<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>--Lindolfo "Lorn" Rodrigues<br><a href="http://www.slackwarezine.com.br">www.slackwarezine.com.br</a><br><a href="http://lornlab.org">http://lornlab.org</a><br>
<a href="http://sao-paulo.pm.org">http://sao-paulo.pm.org</a><br>use Catalyst;<br>