Многопоточность в Perl, или Как я посмотрел ролик о съёмках Warehouse 13

1) Простой скрипт с REMOTE_ADDR — не катит, в REMOTE_ADDR по идее всегда будет тупо адрес проксика, который шлет запрос. Надо проверять HTTP_X_FORWARDED_FOR, HTTP_REAL_IP как минимум, а вообще неплохо бы по всему массиву заголовков пройтись и проверить, т.к. бывают атипичные.
2) Из пункта 1 неявно следует, что 100% полагаться на myip.ru тоже особого смысла нет, т.к. неизвестно какие он IP адреса выдает, из каких «переменных»

Вместо того, чтобы обращаться к некоему HTML-сайту, определяющему IP, выкачивать с десяток килобайт, а затем парсить — не лучше ли использовать ifconfig.me/ip?

Я как-то точно такой же многопоточный скрипт сделал (сначала надеялся на LWP::Parallel::UserAgent, но не получилось) — работает, но памяти жрёт… Для проверки анонимности запроса использовался свой скрипт на хостинге, который проверял наличие лишнего в запросах.

Минусы перловой многопоточности: 1) сколько памяти занимает 100 потоков? — дофига; 2) а если в этих потоках не обращение к медленным web-серверам делать, а что-то более быстрое, — какую долю будет занимать обращение к shared переменным? В Windows и Linux результаты будут немного разные, но общий вывод не очень утешительный.

Увидев картинку, я подумал, вы устройство Фарнсворта сделали и через него посмотрели ролик) Блог «Perl» не разглядел…

Эту задачу можно решить без use threads;
Например, AnyEvent + AnyEvent::HTTP (или обертка над ним).
Если хотим, чтобы выглядело как треды, то use Coro;

Еще один велосипед с тредами и сокетами. Люди, расскажите, кто вас научил распараллеливать сетевые операции тредами? Почему вы не используете select / AnyEvent?

Фиг с ним с перлом. Сериал надо посмотреть. Название правильное.

Какой то странный код даже для обучающего оО

В каком формате список прокси лежит? Если в виде — каждый прокси на строку в файле, то цикл перебора можно упростить до:
# Читаем список проксей
open FIL, 'proxy.lst';
my @proxy = ;
@proxy = grep { /(\d+\.\d+\.\d+\.\d+:\d+)/ } @proxy;
print "Proxies found: ".@proxy."\n";


выборка следующего прокси из массива тоже не особо ясная конструкция, ее можно привести к виду:
# Получаем следующую проксю из списка
my $proxy=shift(@proxy);
# Если список кончился, заканчиваем
unless ($proxy) {
print "- Thread $num done.\n";
return;
}


И вообще лучше не использовать бесконечный цикл с тредами, а использовать AnyEvent.



А без lock при использовании threads::shared будут дублированные проверки проксей.

Имею такую ситуацию: в одной компьютерной сети есть считалка трафика, которая разгребает потоки netflow и складывает результаты в БД.

Считалка написана на Perl и в критические моменты скушивает аж одно ядро процессора. Мне то процессора не жалко, но дело в том что есть ещё 7 ядер которые загружены на 1..2 процента.

Умеет ли Пёрл параллелиться на несколько процессов? или здесь только fork() спасёт ситуацию?
Потому что thread'ы оно хорошо, но с точки зрения планировщика операционной системы это всё-равно остаётся одним процессом.