[SP-pm] AnyEvent::Util::fork_call() e IPC

Stanislaw Pusep creaktive at gmail.com
Wed Jul 11 05:15:25 PDT 2012


Great success :D
Aliás, 2 notas:
1) $AnyEvent::Util::MAX_FORKS assegura que as coisas não saiam do controle.
O valor default (10) é bem modesto.
2) A complexidade da serialização/transferência do resultado do child deve
ser considerada. O edge case, para mim, foi passar string com HTML p/child,
e esse retornar um objeto HTML::Tree. Só valeria a pena em sistemas com > 4
núcleos.

ABS()



2012/7/11 Junior Moraes <juniiior182 em gmail.com>

> Hi.
>
> Wooooooooh, nigga! Lindo!
> Exatamente o que eu queria, e até melhor já que a comunicação é até
> automatizada. =p
>
> Obrigado, Stan! :-D
>
> []'s
>
> Em 10 de julho de 2012 17:59, Stanislaw Pusep <creaktive em gmail.com>escreveu:
>
> Cara, não é bem por aí que se usa fork_call :)
>> Infelizmente, tive que dar um RTFS para cair a ficha, então sua dúvida é
>> mais do que compreensível.
>> Trocando em miúdos, fork_call funciona da seguinte maneira:
>>
>
>> my $cv = AnyEvent->condvar;
>> for my $url (@{$urls}) {
>>     $cv->begin;
>>     fork_call {
>>         return extract_links($url);
>>     } sub {
>>         push @pool, @{shift};
>>         $cv->end;
>>     }
>> }
>> $cv->wait;
>>
>> Traduzindo: o primeiro bloco sub {} é o que rodará dentro do child. O
>> resultado retornado dentro desse bloco sofre um freeze() e é retornado, via
>> canal IPC adequado para o seu OS (pipe em UN*X, socket TCP em Win), para o
>> parent. O segundo bloco roda no parent, recebe o buffer do child, dá um
>> thaw() e retorna em @_. Ou seja, lembre-se disso: o primeiro bloco é child,
>> o segundo é parent. Child herda o escopo léxico do parent, mas somente
>> devolve o q vc quiser retornar.
>>
>> ABS()
>>
>>
>>
>> 2012/7/10 Junior Moraes <juniiior182 em gmail.com>
>>
>>>  Hi.
>>>
>>> Estou tendo um (óbvio) problema pra sharear variáveis utilizando o
>>> método fork_call() do módulo AnyEvent::Util, e como tudo o que eu menos
>>> quero é usar threads, então preciso de ajuda.
>>>
>>> Como o próprio nome do método diz, já esperava ter exatamente este
>>> problema por se tratar de um *fork* visto que um processo não acessa o
>>> outro, mas esperava achar uma solução mais simples pra conseguir fazer o
>>> IPC.
>>>
>>> Alguém já trabalhou com este método e conseguiu obter uma solução
>>> interessante?
>>> Escrevi um código simplório pra vocês entenderem melhor. No caso, o
>>> array *@pool* que vem zerado, já que o push ocorre num processo
>>> separado :(
>>> https://gist.github.com/3086129
>>>
>>> Alguma *fucking* idéia?
>>>
>>> Obrigado desde já!
>>> []'s
>>>
>>>
>>> --
>>>
>>>
>>>  ______________________
>>> < Junior "fvox" Moraes >
>>>  ----------------------
>>>    \
>>>     \
>>>         .--.
>>>        |o_o |
>>>        |:_/ |
>>>       //   \ \
>>>      (|     | )
>>>     /'\_   _/`\
>>>     \___)=(___/
>>>
>>>
>>>
>>> =begin disclaimer
>>>    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>>>  SaoPaulo-pm mailing list: SaoPaulo-pm em pm.org
>>>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
>>> =end disclaimer
>>>
>>>
>>
>> =begin disclaimer
>>    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>>  SaoPaulo-pm mailing list: SaoPaulo-pm em pm.org
>>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
>> =end disclaimer
>>
>>
>
>
> --
>
>
>  ______________________
> < Junior "fvox" Moraes >
>  ----------------------
>    \
>     \
>         .--.
>        |o_o |
>        |:_/ |
>       //   \ \
>      (|     | )
>     /'\_   _/`\
>     \___)=(___/
>
>
>
> =begin disclaimer
>    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>  SaoPaulo-pm mailing list: SaoPaulo-pm em pm.org
>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> =end disclaimer
>
>
-------------- Pr�xima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20120711/d014ae5c/attachment.html>


More information about the SaoPaulo-pm mailing list