Межпроцессовые взаимодействия
Сразу хочу огорчить программистов под Windows. К сожалению, некоторые из описанных ниже рецептов под Windows работать не будут. Я и сам долго скрежетал зубами, когда в ответ на переопределение STDOUT с помощью разветвляющего open в логи валились сообщения о том, что, мол, нет такой команды. Кого уж тут винить, не знаю и искать не собираюсь. А советую всем, дабы не тратить свое драгоценное время, писать свои программы с расчетом на UNIX. Честно говоря, после всего что я пережил, программируя под Windows, и узнав, что хостинг на IIS гораздо дороже (как очень редкий зверь что ли?) чем на UNIX-ах, я чуть из кресла не вывалился.
Процессы и с чем их едят
Давным-давно в одной далекой галактике жил-был DOS. И было у него всего-то навсего 640 килов памяти, и мог выполнять он лишь только одну задачу. И появился грозный монстр Windows, который разделил процессорное время на части. Одну часть отвел он сонмищу процесов, а другую часть - сонмищу потоков. И перекликались они с помощью мьютексов и семафоров. А данные передавались где как: Была там и общая куча (heap), и пайпы кой где работали: В общем рассказывать дальше думаю не имеет смысла. Еще много чего можно написать - все это скучно и отвлекает от основных целей.
Так как все здесь описанное связанно с Perl, который проектировался с ориентировкой на UNIX-системы (я об этом не читал, это мой собственный вывод - если не прав, можете поправить), все системные фишки, которые здесь будут расмотрены, относятся именно к UNIX-системам. Конечно, реализация Perl для Windows скрывает кое-какие несоответствия, но далеко не все. Так что, сильно не огорчайтесь, если что-то не работает. Безвыходных ситуаций не бывает. Пишите в форум, а еще лучше побольше экспериментируйте - тогда все получится.
Итак, процесс - это программа, код которой выполняется независимо от других программ. Может быть это и не академическое определение, но ведь и наша задача не обозвать это правильно, а понять - как это работает и какая нам может быть от этого польза. Дабы не углубляться в системные тонкости, представим ситуацию на известных нам примерах.
Программа, написанная на Perl, содержит несколько процедур. При вызове процедуры, интерпретатор выполняет последовательность операций, составляющих процедуру - тело процедуры. Тут важно выделить что эта последовательнось, мало зависит от последовательности операторов другой процедуры. В процедуре могут быть определены локальные переменные. Эти переменные так же не имеют отношения к переменным, используемым в других процедурах, даже если имена у них одинаковые. При этом, какая-то часть кода, которая находится вне всяких процедур, управляет работой программы в целом - когда нужно вызывает процедуры, что-то там еще творит, и так далее.
Так вот, можно привести аналогию с многозадачной операционной системой: код вне процедур здесь будет представлять код ядра, который управляет всеми процессами-процедурами. Но здесь маленькое но важное примечание. Когда в нашей аналогии ядро вызывает процедуру это запуск процесса, но не ее выполнение и ожидание ее завершения. Ядро где-то там у себя в хэше процесов создает новую пару имя-значение, имя которого есть имя процедуры, а значение - номер строки последовательности операторов процедуры, на которой остановилось выполнение (то есть после запуска это 0). После этого, ядро перебирает все ключи из хэша смотрит на имя и номер строки. Переходит на эту строку в нужной процедуре и выполняет, к примеру, следующие пять строк. Дальше следующая процедура, так до конца, а потом опять в начало хэша.
Ну вот, у нас получилась примитивная многозадачная среда. Даже ее можно с лету усложнить. Например, добавить понятие приоритета процеса. В нашем примере, чем выше приоритет, тем больше строк процедуры будет выполняться в каждой итерации перебора всех процессов-процедур.
На самом деле все гораздо сложнее. Но нам не обязательно знать как работает ядро операционной системы для того что бы воспользоваться преимуществами многозадачной среды. Достаточно знать, что процесс - это программа, выполняющийся независимо. Очень важно уяснить, что процесс это не только код, но и данные. Даже если запускаются две одинаковые программы, данные они, скорее всего, будут обрабатывать по разному.
С точки зрения программирования, когда речь не идет о запуске другой программы, в Perl создание (порождение) нового процесса - это создание дубликата текущей программы. При этом еще раз подмечу, что дублируется не только код, но и все переменные с их значениями. Все делается не просто, а очень просто
fork;
и после этого оператора у вас выполняются два совершенно одинаковых процесса. Ну, конечно от программы, выполняющий оператор fork в таком виде, толку мало, разве что если вы хотите насолить системному администратору, пожирая системные ресурсы, запустив этот оператор в бесконечном цикле.
На самом деле, оператор fork возвращает значение, которое используется для определения процесса. К примеру, выходит человек из-за угла, а ему кирпичом по голове. Очнулся, а в руке у него на бумажке написано - ты номер 1. Он встал и пошел дальше. Пойти то пошел, да на его месте опять же этот человек лежит. А у него в руке бумажка, на которой написано - ты номер 2. Этот человек поднялся, подумал, что сейчас вот зайду за другой угол, а там опять кирпичом по голове дадут, и пошел в другую сторону.
Так вот, вернемся к нашим баранам. Одному процесу достается значение, идентифицирующее порожденный процесс. То есть, дописываем в бумажку первого человека фразу типа "у второго номер 2". Это бывает необходимым в случае если подразумевается взаимодействие с порожденным процессом. Порожденный процесс, получает от fork значение 0. Но возможны такие ошибочные ситуации, когда создать процесс не удалось. Возвращаясь к нашему примеру, человек заходит за угол и: Ничего не происходит. Человек думает, странно, здесь на меня должен упасть кирпич, видимо погода нелетная. Разворачивается и идет домой. Когда fork не возвращает значения (undef), значит породить процесс не удалось. Это, несомненно, ошибочная ситуация и ее необходимо обработать. В общем случае вызов fork должен выглядеть так
unless defined(fork) {
print "обработайте ошибку, или вместо этого вызовите die"
}
Наверное вас уже перекрючило, в тщетных попытках отрывания пальцев от любимой клавиатуры. Давайте попробуем применить наши знания о fork на каком нибудь (как всегда бесполезном) примере.
#!/usr/bin/perl -w # fork.pldie "Non-flying weather" unless defined(fork); print "I'm number $$\n";
В результате выполнения вы увидете что-то вроде
[root@avalon tests]# ./fork.pl I'm number 6773 I'm number 6774
Так как процессы полностью дублируются, каждый процесс получает собственную копию данных, включая файловые дескрипторы и дескрипторы потоков ввода-вывода. Таким образом, оператор print в обоих процессах работает с одним и тем же дескриптором. Если кто не знает, встроенная переменная $$ содержит идентификатор текущего процесса Perl. Кстати, в качестве домашнего задания, можете добавить код,показывающий значение переменной $$ до выполнения fork. Тогда вы увидете, какой процесс является родительским и сделать вывод - в какой последовательности два дубликата начинают работать.
Да, чуть не забыл, важно завершать процесс оператором exit. Ну, думаю, хватит с вас бесполезной писанины. Пора заняться что нибудь более серьезным.
Фильтрация выходных данных
Сколько познаю Perl, все не перестаю удивляться. Столько приятных сюрпризов не встречал еще нигде. Сам язык настолько логичен (если можно так выразиться), что открывает все свои тайны внимательному программисту, причем без частого обращения к документации. Вот и давеча, возникла у меня необходимость отфильтровать выходные данные некой CGI-программы:
Погодите разминать пальцы. Сначала выпьем по кружке кофею, а я, в это время, обрисую ситуацию в целом. Что такое фильтр на выходные данные всем понятно? Ну если кому не понятно, то опять же - представим. Программа что то там выводит в STDOUT (стандартный поток вывода), а в это время какая-то другая программа тихо и незаметно ворует эти данные и делает с ними все что заблагорассудится. Реальный пример? Ну самое первое что пришло мне в голову - это замена всех URL на гиперссылки. Или в помощь расеянному программисту, вечно забывающему о HTTP-заголовках, проверять наличие оных заголовков и добавлять их если нужно. На самом деле, все может быть гораздо сложнее. Например, вырезание ненормативной лексики (этакий невидимый цензор) из текста сообщения, отправляемого посредством WEB-интерфейса, перед тем, как оно будет передаваться на вход SENDMAIL. Ну и в таком духе.
В общем, первая наша цель, это каким-то образом подсунуть новый STDOUT, который мы можем прочитать, программе, вывод от которой мы будем фильтровать. Но тут возможны варианты. Например, может быть мы хотим организовать вывод по типу транзакции: или программа выполняется до конца, и выводится все содержимое, или же, в случае ошибки нужно сбросить данные, а вывести, например, LOCATION на страницу обработки ошибок. То есть, все зависит от уровня контроля над фильтруемым выходным потоком. Что бы совсем стало понятно, о чем я здесь распинаюсь, давайте напишем простой примерчик, демонстрирующий "тупой" фильтр-нумератор строк.
#!/usr/bin/perl -w
# nfilter.plfilter();
for ($I = 0; $I < 20; $I +){
print "Output line\n";
}
sub filter{
die "Cannot fork"
unless defined($fpid = open(STDOUT,"-"));
return if ($fpid != 0);
num = 0;
while (<>) {
print "$num:\t$_";
$num ++;
}
exit;
}
Не вздумайте запускать. Что, уже запустили? Тогда жмите Ctrl+C. За-то теперь навсегда запомните - нужно закрывать дескрипторы (желательно все :). В чем же дело? Почему программа зависла? Все порожденные процесы являются процессами единой задачи. Потоки ввода вывода автоматически закрываются, когда завершается последний процесс. Конструкция open(STDOUT, "-") неявно вызывает fork. Вспомните документацию по файловым операциям:
open(HANDLE, " $cmd"); # направить информацию на вход программы
Так вот, здесь аналогичная ситуация, только в качестве программы здесь создается дочерний процесс. А так как в качестве дескриптора мы указываем STDOUT, то в настоящем процессе он переопределяется. Как и в случае с fork, относительно данных - дублируется их состояние на момент перед вызовом fork. Таким образом, в дочерний процесс попадает нормальный не переопределенный STDOUT. Замечу, что open с указанными аргументами неявно вызывает fork, а в качестве результата возвращает те же самые значения, что и fork. Далее, программа определяет в каком она потоке - если не в порожденном ($fpid != 0), тогда возвращается и эмулирует вывод строк. Сам фильтр читает STDIN пока не закончатся данные. А данные закончатся, когда поток ввода будет закрыт (для родительского процеса, это поток вывода). Родительский процес уже завершил свою работу, а система ждет когда завершится последний процесс, что бы закрыть потоки. И так далее, и так далее. Чувствуете, где собака зарыта? После того, как вывод строк завершен, необходимо закрыть поток вывода, что бы фильтр, принимающий выходные данные через поток ввода вышел из цикла
while (<>) { print "$num:\t$_"; $num ++; }
Вот так то, берем и правим
#!/usr/bin/perl -w
# nfilter.plfilter();
for ($I = 0; $I < 20; $I +){
print "Output line\n";
}close(STDOUT);
sub filter{
die "Cannot fork"
unless defined($fpid = open(STDOUT,"-"));
return if ($fpid != 0);
num = 0;
while (<>) {
print "$num:\t$_";
$num ++;
}
exit;
}
Ну это конечно, дюже примитивно. Но если нам нужно только лишь фильтровать, поток вывода, то сойдет. А вот если мы, например, пишем супер-систему обработки ошибок, то этого все-таки маловато. Представим, что этакий сторож фильтрует вывод и сразу отправляет его в настоящий STDOUT. А если возникла фатальная ошибка? Мы выводим сообщение об ошибке, но все это в догонку тому хламу, что уже был отправлен в STDOUT. Такая обработка ошибок, как говорится, "что мертвому припарка". Можно, конечно, накапливать вывод внутри фильтра и выводить только целиком. В случае чего, можно пришибить порожденный процес с помощью оператора kill. Но увы, поток вывода уже переопределен безвозвратно.
Для решения этой проблемы мы должны кардинально изменить свое мировоззрение. Шучу, конечно. Достаточно вспомнить о таких полезных функциях как select и pipe. Функция select подменяет STDOUT новым дескриптором, а возвращает дескриптор потока вывода, который был актуален на момент до выполнения select, иначе говоря текущий STDOUT. Функция pipe связывает два дескриптора в режиме чтения-записи, то есть создает односторонний канал обмена данными. Отсюда и название - pipe.
Есть очень замечательное свойство систем UNIX - все потоки равны. Прям, коммунизм какой-то. Вот дедушка Ленин бы порадовался. А нам какая с этого польза? Ну как, мы, например, легко можем подсунуть функции select один из дескрипторов, связанных функцией pipe. Естественно, что будем подсовывать тот, который предназначен для записи, иначе я за последствия не ручаюсь. В общем такая незамысловатая программулина
#!/usr/bin/perl -w
# errfilter.plmy ($fpid,$oldout);
pipe(FOR_READ,FOR_WRITE);
select((select(FOR_READ),$ = 1)[0]);
select((select(FOR_WRITE),$ = 1)[0]);
start_filter();
for ($I = 0; $I < 20; $I +){
print "Output line\n";
}
# Error("bug");
close(FOR_WRITE);
waitpid($fpid,0);
sub start_filter{
die "Cannot fork"
unless defined($fpid = fork);
unless ($fpid == 0){
close(FOR_READ);
$oldout = select(FOR_WRITE);
return;
}
close(FOR_WRITE);
my ($out,$num) = ("",0);
while() {
$out .= "$num\t$_"; $num ++;
}
close(FOR_READ);
print $out;
exit;
}
sub Error{
my ($error_text) = @_;
select($oldout);
kill KILL => $fpid;
close(FOR_WRITE);
print "Error: $error_text\n";
exit;
}
Ну что, налили очередную порцию кофе? Тогда приступим к разбору полетов. Первым делом, программа связывает два дескриптора FOR_READ и FOR_WRITE в канал с помощью pipe. При этом, FOR_READ получится только для чтения, а FOR_WRITE, соответственно, только для записи. Про следующие две строки скажу только что они отключают буфферизацию. Для нас это пока не важно, их можно вообще убрать. Далее вызывается функция start_filter(). Вот на нее нужно взгянуть со всей внимательностью.
Первым делом, функция создает дубликат процесса. В родительском процессе закрывается ненужный дескриптор для чтения, а в качестве STDOUT подсовывается один конец созданного канала, тот который только для записи. После этого программа родительский процес возвращается к своему основному бесполезному занятию, а точнее - эмулирует вывод. После того, как вывод завершен, не забываем закрыть дескриптор вывода, иначе все повиснет по причине вышеописанной. Далее ждем, когда дочерний поток завершится (можете закомментировать эту строку, и посмотреть что получится). На этом работа основного процесса завершена.
Вернемся к функции start_filter() в той его части, где выполняется непосредственно фильтрация. Первым делом неиспользуемый в дочернем процессе конец канала закрывается. Далее, процесс в цикле считывает данные из канала и конкатенирует их в переменной $out. Ну далее должно быть все понятно. Запустите программу. Работает?По крайней мере должна.
Теперь уберите комментарии из строки, где вызывается функция Error("bug"). Запустите программу снова. Ну, каков результат? Этого мы добивались? (Правильный ответ да, если нет, то смотрите что вы там понаписали).
Давайте посмотрим, что делает функция Error(). Первым делом восстанавливает стандартный поток вывода. В это время дочерний процесс в режиме накопления данных ничего об этом не подозревает. Следующая жестокая операция убивает дочерний процес. А дочерний процес еще ничего не вывел в поток вывода. После закрывается дескриптор для записи, и выполняется обработка ошибки. Ну и что бы миновать последние строки головного процесса выполняется exit.
Вот и все. Как уж вы будете применять полученную информацию на практике, дело ваше.
Оставить комментарий
Комментарии
Может кто подскажет в чём дело? (может не у меня отного проблема.)