Olá Blabos,<br><br><div class="gmail_quote">2010/7/10 Blabos de Blebe <span dir="ltr">&lt;<a href="mailto:blabos@gmail.com">blabos@gmail.com</a>&gt;</span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Desculpe a minha ignorância e o meu estado sonolerdo, mas por que vc<br>
faz join dentro do loop que cria a thread?<br>
<br>
Eu posso ter entendido errado, mas se for isso vc não está<br>
serializando as threads?<br></blockquote><div><br></div><div>Também não tenho certeza (afinal o código não é meu :P), mas acho que o que ele faz naquele loop interno é se o número de threads existentes for maior que o limite dele (250 no caso), ele entre no loop e faz join em uma das threads, para esperar que ela possa acabar e disparar uma nova thread.</div>
<div><br></div><div>Além disso, como ele faz o segundo loop interno baseado no retorno da listagem de &quot;threads::joinable&quot;, que são threads que já acabaram seu processamento e estão apenas esperando para serem finalizadas e puxar o resultado delas de volta, então as operações de join() ai são não bloqueantes.</div>
<div><br></div><div><br></div><div>Apenas frisando, minha experiência real em aplicações paralelas é baixa, então se eu disser alguma besteira grande por favor me avisem/corrijam.</div><div><br></div><div><br></div><div>João, será que utilizando algo como Thread::Pool[1] ou Thread::Pool::Simple[2] seu código não ficaria mais organizado?</div>
<div><br></div><div>Segundo o perldoc perlthrtut[3]:</div><div>&quot;Performance considerations</div><div>       The main thing to bear in mind when comparing Perl&#39;s ithreads to other threading models is the fact that for each new thread created, a complete copy of all the variables</div>
<div>       and data of the parent thread has to be taken. Thus, thread creation can be quite expensive, both in terms of memory usage and time spent in creation. The ideal way to</div><div>       reduce these costs is to have a relatively short number of long-lived threads, all created fairly early on -- before the base thread has accumulated too much data. Of</div>
<div>       course, this may not always be possible, so compromises have to be made. However, after a thread has been created, its performance and extra memory usage should be little</div><div>       different than ordinary code.&quot;</div>
<div><br></div><div>Principalmente a parte do: &quot;Thus, thread creation can be quite expensive, both in terms of memory usage and time spent in creation.&quot;.</div><div>Será que aqui uma implementação utilizando uma pool de threads (como sugerido acima), não seria melhor? :)</div>
<div><br></div><div>(ps: eu não sei o quanto atualizado está essa documentação, mas ela está presente no perldoc do perl 5.12.1)</div><div><br></div><div><br></div><div>[1] <a href="http://search.cpan.org/~elizabeth/Thread-Pool-0.32/lib/Thread/Pool.pm">http://search.cpan.org/~elizabeth/Thread-Pool-0.32/lib/Thread/Pool.pm</a></div>
<div>[2] <a href="http://search.cpan.org/~jwu/Thread-Pool-Simple-0.24/Simple.pm">http://search.cpan.org/~jwu/Thread-Pool-Simple-0.24/Simple.pm</a></div><div>[3] <a href="http://perldoc.perl.org/perlthrtut.html">http://perldoc.perl.org/perlthrtut.html</a></div>
<div><br></div><div><br></div><div>[ ]&#39;s</div></div>-- <br>Bruno C. Buss<br><a href="http://brunobuss.wordpress.com/">http://brunobuss.wordpress.com/</a><br><a href="http://www.dcc.ufrj.br/~brunobuss/">http://www.dcc.ufrj.br/~brunobuss/</a><br>