LINUX.ORG.RU
решено Форум — Development  

[Perl][Threads] ЧЯДНТ?

 


0

1 
  1 #!/usr/bin/perl
  2 
  3 use Thread 'yield';
  4 
  5 #my $var : shared = 1;
  6 
  7 sub myFunc { 
  8  my($link) = @_;
  9  
 10  while($$link) { yield; }
 11 }
 12 
 13 $var = 1;
 14 $t = Thread->new(\&myFunc, \$var);
 15 $var = 0;
 16 
 17 $t->join();

myFunc() вернёт, только если раскоментировать 5 строчку. Сильно не бить: с потоками в Perl работаю впервые, а в кемеле (3-е издание, для perl 5.6) почему-то про shared вобще ничего не пишут.

вот это я понимаю, прямо какая-то рекурсия в заголовке, причём содержит ответ на вопрос и при этом сам вопрос можно не читать.

[Perl][Threads] ЧЯДНТ?


ответ: [Perl][Threads]

dimon555 ★★★★★
()

А что непонятного-то? Если раскомментировать 5ю строчку, $var будет видна в обоих тредах, и когда в 15й строке она будет выставлена в 0, while завершится.

anonymous
()
Ответ на: комментарий от markevichus

Как бы пофиг. Почитай как работают треды в перле - на каждый тред создается новый процесс интепритатора. «Since Perl 5.8, thread programming has been available using a model called interpreter threads which provides a new Perl interpreter for each thread, and, by default, results in no data or state information being shared between threads.» ...Иначе зачем ты думаеш сделали отдельно threads::shared? И да - не юзай треды в перле ) Треды в перле - ацтой. Юзай fork(). Или же как вариант различные готовые модули из cpan, например forks (дико удобная штука. API идентичное threads , но реализовано все через fork()),IPC::Fork::Simple,Parallel::ForkManager ну и тд, use CPAN короче.

anonymous
()
Ответ на: комментарий от anonymous

И да - не юзай треды в перле ) Треды в перле - ацтой. Юзай fork().

А если достаточно сложные данные нужно шарить? Треды в перле да, неудобные, да, нужно знать как они работают, но жить можно. В отличии от питона хоть какое-то распараллеливание.

Vovka-Korovka ★★★★★
()
Ответ на: комментарий от anonymous

> А что непонятного-то? Если раскомментировать 5ю строчку, $var будет видна в обоих тредах, и когда в 15й строке она будет выставлена в 0, while завершится.

Так вроде без «use thread::shared» и с пятой строкой не должно работать.

kim-roader ★★
()
Ответ на: комментарий от anonymous

>Почитай как работают треды в перле - на каждый тред создается новый процесс интепритатора.
Да, это я знаю. Примеры в книге оказались нерабочими с моей версией интерпретатора.

У меня есть слушающий tcp-сервер, который принимает задание на выполнение. Сам сервер - это один поток, а испольнительная часть (которая может работать по несколько часов) кода - второй.
Нужно, чтобы система могла реагировать на команды, пришедшие во время исполнения к-л задания.
Можно организовать общение между процессами, конечно.

Или же как вариант различные готовые модули из cpan, например forks

Ok. Почитаю. Спасибо.

markevichus ★★★
() автор топика
Ответ на: комментарий от markevichus

> Нужно, чтобы система могла реагировать на команды, пришедшие во время исполнения к-л задания.
тогда это раелизуется через две отдельные програмы: локальный демон и интерфейсный CGI-скрипт.

xydo ★★
()
Ответ на: комментарий от xydo

Я к тому же: наверное, нет случаев, при которых нельзя было бы обойтись без потоков. Хотя бы в серверных приложениях.
Я получил ответ по поводу использования тредов в perl. Всем спасибо.

markevichus ★★★
() автор топика
Ответ на: комментарий от Vovka-Korovka

А если достаточно сложные данные нужно шарить? Треды в перле да, неудобные, да, нужно знать как они работают, но жить можно. В отличии от питона хоть какое-то распараллеливание.

Ну понятно что все зависит от задачи. И плюс еще вопрос в том, как шарить? Если вам надо иметь read доступ к большому обьему данных, то тут тоже идеально подходит fork() так как при создании новых процессов, будет использоватся механизм Copy-On-Write и данные по 10 раз не будут дублироватся, и будут занимать меньше места. Если нужно постоянно чтото менять, кучей поток в общих данных - это скажем так, не совсем гуд, куча потерь на мьютексах/семафорах. Если вам скажем надо вернуть в дочерний процесс, результаты работы, то тут опять же, время затрачено на обработку результатов скорее всего будет ощутимо больше чем время для передачи этих данных в дочерний процесс, даже через сокеты... Короче всегда надо смотреть конкретно, универсального решения конечно же нету...

PS: както сумбурно все написал )
PPS:Вообще я хз, есть ли нормальная реализация тридов в каком то из популярных скриптовых языков?

anonymous
()
Ответ на: комментарий от markevichus

У меня есть слушающий tcp-сервер, который принимает задание на выполнение. Сам сервер - это один поток, а испольнительная часть (которая может работать по несколько часов) кода - второй. Нужно, чтобы система могла реагировать на команды, пришедшие во время исполнения к-л задания. Можно организовать общение между процессами, конечно.

Ну я хз если честно зачем тебе тут треды. Тут отлично ложится fork() модель. Воркеры запустились, основной процесс обрабатывает запросы от других клиентов, воркеры закончили работу - отдали результаты в main process. Я думаю тебе стоит еще почитать на тему AnyEvent - это такой очень удобный фреймворк для event-driven програмирования. Ты в целом можеш заюзать для долговыполняющихся задач его AnyEvent::Util::fork_call , а всю основную работу по взаимодействию с клиентами выполнять на основе событий.

anonymous
()
Ответ на: комментарий от markevichus

Я к тому же: наверное, нет случаев, при которых нельзя было бы обойтись без потоков. Хотя бы в серверных приложениях.

Оу! Сейчас же читать сначала http://en.wikipedia.org/wiki/Event-driven_programming Потом о его приложении к перлу http://search.cpan.org/~mlehmann/AnyEvent-6.1/

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Development