On 10/19/06, Tacio Santos <[EMAIL PROTECTED]> wrote:
Olá,
para variar um pouco uma questão sobre ruby :-)
Estava fazendo algums testes com o uso de threads em ruby e esbarrei
no sequinte problema: preciso acessar vários recursos do sistema
operacional ao mesmo tempo sendo que alguns deles bloqueiam o
interpretador. Pergunta: existe alguma forma de fazer isso sem criar
novos processos com novos interpretadores para cada processo ou isso é
mesmo uma limitação do Ruby pelo fato dele não suportar threads
nativas?
Em ambientes Unix/Linux, os threads de Ruby funcionam relativamente bem, sem travar toda a aplicação (pelo menos às vezes). Por exemplo, eu tenho um editor de Ruby que eu fiz, e quando lanço um novo interpretador para executar o arquivo no editor, e como quero capturar a saída desse novo interpretador para usar as informações para depuração, então no Linux isso funciona tranquilo, usando uma combinação de "Thread/Fork/.gets". No Windows, trava o editor, que só é liberado quando o novo interpretador é fechado.
No Windows, Perl emula o "Fork" e deixa essas coisas funcionarem melhor eu acho. Também, como você falou, Python suporta Threads nativos, o que torna Python melhor em Windows se você precisa disso. Já Ruby, não emula o "Fork" e nem tem Threads nativos em Windows ainda. Só com a versão 2.0 de Ruby para resolver essa questão de Threads nativos, pois Ruby em ambientes Unix/Linux nem precisa deles normalmente.
Se você está em ambiente Unix/Linux, existem formas de evitar o bloqueamento da aplicação. As técnicas seguem os padrões Unix/Linux de sempre. Eu não tenho idéia do que pode estar travando a sua aplicação. Uma idéia é usar o ".select" no IO para checar se tem algo para ser lido. Outra é usar "fork" (mais processos) junto com thread se funcionar.
Tirando o meu editor de Ruby e o meu cliente de IRC, eu pouco mexi com isso. Mas as coisas vão melhorar no Ruby 2.0. Tomara. :-)
Joao,
http://ralip.com.br/jp/blog/
_______________________________________________ Ruby-l mailing list [email protected] http://www.listas.unicamp.br/mailman/listinfo/ruby-l
