Текст книги "Основы программирования в Linux"

Автор книги: Нейл Мэтью

Соавторы: Ричард Стоунс
сообщить о нарушении

Текущая страница: 43 (всего у книги 67 страниц)

Ожидание процесса

Когда вы запускаете дочерний процесс с помощью вызова fork, он начинает жить собственной жизнью и выполняется независимо. Иногда вам нужно знать, когда закончился дочерний процесс. Например, в предыдущей программе родительский процесс завершается раньше дочернего, и вы получаете слегка беспорядочный вывод, потому что дочерний процесс продолжает выполняться. Вы можете с помощью системного вызова wait заставить родительский процесс дождаться завершения дочернего процесса перед своим продолжением.

#include

#include

pid_t wait(int *stat_loc);

Системный вызов wait заставляет родительский процесс сделать паузу до тех пор, пока один из его дочерних процессов не остановится. Вызов возвращает PID дочернего процесса. Обычно это дочерний процесс, который завершился. Сведения о состоянии позволяют родительскому процессу определить статус завершения дочернего процесса, т.е. значение, возвращенное из функции main или переданное функции exit. Если stat_loc не равен пустому указателю, информация о состоянии будет записана в то место, на которое указывает этот параметр.

Интерпретировать информацию о состоянии процесса можно с помощью макросов, описанных в файле sys/wait.h и приведенных в табл. 11.2.

Таблица 11.2

WIFEXITED(stat_val)	Ненулевой, если дочерний процесс завершен нормально
WEXITSTATUS(stat_val)	Если WIFEXITED ненулевой, возвращает код завершения дочернего процесса
WIFSIGNALED(stat_val)	Ненулевой, если дочерний процесс завершается неперехватываемым сигналом
WTERMSIG(stat_val)	Если WIFSIGNALED ненулевой, возвращает номер сигнала
WIFSTOPPED(stat_val)	Ненулевой, если дочерний процесс остановился
WSTOPSIG(stat_val)	Если WIFSTOPPED ненулевой, возвращает номер сигнала

Выполните упражнение 11.4.

Упражнение 11.4. Системный вызов wait

В этом упражнении вы слегка измените программу, чтобы можно было подождать и проверить код состояния дочернего процесса. Назовите новую программу wait.c.

#include

#include

#include

#include

#include

int main() {

 pid_t pid;

 char* message;

 int n;

 int exit_code;

 printf(«fork program startingn»);

 pid = fork();

 switch(pid) {

 case -1:

  perror(«fork failed»);

  exit(1);

 case 0:

  message = «This is the child»;

  n = 5;

  exit_code = 37;

  break;

 default:

  message = «This is the parent»;

  n = 3;

  exit_code = 0;

  break;

 }

 for (; n > 0; n–) {

  puts(message);

  sleep(1);

 }

Следующий фрагмент программы ждет окончания дочернего процесса:

 if (pid != 0) {

  int stat_val;

  pid_t child_pid;

  child_pid = wait(&stat_val);

  printf(«Child has finished: PID = %dn», child_pid);

  if (WIFEXITED(stat_val))

   printf(«Child exited with code %dn», WEXITSTATUS(stat_val));

  else printf(«Child terminated abnormallyn»);

 }

 exit(exit_code);

}

Когда вы выполните эту программу, то увидите, что родительский процесс ждет дочерний:

$ ./wait

fork program starting

This is the child

This is the parent

This is the parent

This is the child

This is the parent

This is the child

This is the child

This is the child

Child has finished: PID = 1582

Child exited with code 37

$

Как это работает

Родительский процесс, получивший ненулевое значение, возвращенное из вызова fork, применяет системный вызов wait для приостановки своего выполнения до тех пор, пока информация о состоянии дочернего процесса не станет доступной. Это произойдет, когда дочерний процесс вызовет функцию exit; мы присвоили ему код завершения 37. Далее родительский процесс продолжается, определяет, протестировав значение, возвращенное вызовом wait, что дочерний процесс завершился нормально, и извлекает код завершения из информации о состоянии процесса.

Процессы-зомби

Применение вызова fork для создания процессов может оказаться очень полезным, но вы должны отслеживать дочерние процессы. Когда дочерний процесс завершается, связь его с родителем сохраняется до тех пор, пока родительский процесс в свою очередь не завершится нормально, или не вызовет wait. Следовательно, запись о дочернем процессе не исчезает из таблицы процессов немедленно. Становясь неактивным, дочерний процесс все еще остается в системе, поскольку его код завершения должен быть сохранен, на случай если родительский процесс в дальнейшем вызовет wait. Он становится умершим или процессом-зомби.

Вы сможете увидеть создание процесса-зомби, если измените количество сообщений в программе из примера с вызовом fork. Если дочерний процесс выводит меньше сообщений, чем родительский, он закончится первым и будет существовать как зомби, пока не завершится родительский процесс.

Упражнение 11.5. Зомби

Программа fork2.c такая же, как программа fork1.с, за исключением того, что количества сообщений, выводимых родительским и дочерним процессами, поменяли местами. Далее приведены соответствующие строки кода:

switch (pid) {

case -1:

 perror(«fork failed»);

 exit(1);

case 0:

 message = «This is the child»;

 n = 3;

 break;

default:

 message = «This is the parent»;

 n = 5;

 break;

}

Как это работает

Если вы выполните только что приведенную программу с помощью команды ./fork2 & и затем вызовите программу ps после завершения дочернего процесса, но до окончания родительского, то увидите строку, подобную следующей. (Некоторые системы могут сказать вместо .)

$ ps -аl

  F S UID  PID PPID С PRI NI ADDR SZ WCHAN  TTY   TIME     CMD

004 S   0 1273 1259 0  75  0 –   589 wait4  pts/2 00:00:00 su

000 S   0 1274 1273 0  75  0 –   731 schedu pts/2 00:00:00 bash

000 S 500 1463 1262 0  75  0 –   788 schedu pts/1 00:00:00 oclock

000 S 500 1465 1262 0  75  0 –  2569 schedu pts/1 00:00:01 emacs

000 S 500 1603 1262 0  75  0 –   313 schedu pts/1 00:00:00 fork2

003 Z 500 1604 1603 0  75  0 –     0 do_exi pts/1 00:00:00 fork2

000 R 500 1605 1262 0  81  0 –   781 –      pts/1 00:00:00 ps

Если родительский процесс завершится необычно, дочерний процесс автоматически получит в качестве родителя процесс с PID, равным 1 (init). Теперь дочерний процесс – зомби, который уже не выполняется, но унаследован процессом init из-за необычного окончания родительского процесса. Зомби останется в таблице процессов, пока не пойман процессом init. Чем больше таблица, тем медленнее эта процедура. Следует избегать процессов-зомби, поскольку они потребляют ресурсы до тех пор, пока процесс init не вычистит их.

Есть еще один системный вызов, который можно применять для ожидания дочернего процесса. Он называется waitpid и применяется для ожидания завершения определенного процесса.

#include

#include

pid_t waitpid(pid_t pid, int *stat_loc, int options);

Аргумент pid – конкретный дочерний процесс, окончания которого нужно ждать. Если он равен –1, waitpid вернет информацию о любом дочернем процессе. Как и вызов wait, он записывает информацию о состоянии процесса в место, указанное аргументом stat_loc, если последний не равен пустому указателю. Аргумент options позволяет изменить поведение waitpid. Наиболее полезная опция WNOHANG мешает вызову waitpid приостанавливать выполнение вызвавшего его процесса. Ее можно применять для выяснения, завершился ли какой-либо из дочерних процессов, и если нет, то продолжать выполнение. Остальные опции такие же, как в вызове wait.

Итак, если вы хотите, чтобы родительский процесс периодически проверял, завершился ли конкретный дочерний процесс, можно использовать следующий вызов:

waitpid(child_pid, (int *)0, WNOHANG);

Он вернет ноль, если дочерний процесс не завершился и не остановлен, или child_pid, если это произошло. Вызов waitpid вернет -1 в случае ошибки и установит переменную errno. Это может произойти, если нет дочерних процессов (errno равна ECHILD), если вызов прерван сигналом (EINTR) или аргумент options неверный (EINVAL).

Перенаправление ввода и вывода

Вы можете применить ваши знания о процессах для изменения поведения программ, используя тот факт, что открытые файловые дескрипторы сохраняются вызовами fork и exec. Следующий пример из упражнения 11.6 содержит программу-фильтр, которая читает из стандартного ввода и пишет в свой стандартный вывод, выполняя при этом некоторое полезное преобразование.

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

#include

#include

#include

int main() {

 int ch;

 while ((ch = getchar()) != EOF) {

  putchar(toupper(ch));

 }

 exit(0);

}

Когда вы выполните программу, она сделает то, что и ожидалось:

$ ./upper

hello THERE

HELLO THERE

^D

$

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

$ cat file.txt

this is the file, file.txt, it is all lower case.

$ ./upper < file.txt

THIS IS THE FILE, FILE.TXT, IT IS ALL LOWER CASE.

Что если вы хотите применить этот фильтр из другой программы? Программа useupper.c принимает имя файла как аргумент и откликается сообщением об ошибке при некорректном вызове:

#include

#include

#include

int main(int argc, char *argv[]) {

 char *filename;

 if (argc != 2) {

  fprintf (stderr, «usage: useupper filen»);

  exit(1);

 }

 filename = argv[1];

Вы повторно открываете стандартный ввод, снова при этом проверяете наличие любых ошибок, а затем применяете функцию execl для вызова программы upper:

 if (!freopen(filename, "r", stdin)) {

  fprintf(stderr, «could not redirect stdin from file %sn», filename);

  exit(2);

 }

 execl(«./upper», «upper», 0);

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

 perror(«could not exec ./upper»);

 exit(3);

}

Как это работает

Когда вы выполняете эту программу, ей можно передать файл для преобразования в прописные буквы. Работа делается программой upper, которая не обрабатывает аргументы с именами файлов. Обратите внимание на то, что вам не нужен исходный код программы upper; таким способом можно запустить любую исполняемую программу.

$ ./useupper file.txt

THIS IS THE FILE, FILE.TXT, IT IS ALL LOWER CASE.

Программа useupper применяет freopen для закрытия стандартного ввода и связывания потока файла с файлом, заданным как аргумент программы. Затем она вызывает execl, чтобы заменить код выполняемого процесса кодом программы upper. Поскольку файловые дескрипторы сохраняются, пройдя сквозь вызов execl, программа upper выполняется так же, как при вводе ее в строке командной оболочки

$ ./upper < file.txt

Потоки

Процессы Linux могут взаимодействовать, отправлять друг другу сообщения и прерываться друг другом. Они могут даже организоваться и совместно использовать сегменты памяти, но они остаются обособленными объектами операционной системы. Процессы не настроены на совместное использование переменных.

Существует класс процесса, именуемый потоком (thread), который доступен во многих системах UNIX и Linux. Несмотря на то, что потоки трудно, программировать, они могут быть очень важны для некоторых приложений, таких как многопоточные серверы баз данных. Программирование потоков в Linux (и вообще в UNIX) не так распространено, как применение множественных процессов, поскольку процессы Linux очень легко применять и программирование множественных взаимодействующих процессов гораздо легче программирования потоков. Потоки обсуждаются в главе 12.

Сигналы

Сигнал – это событие, генерируемое системами UNIX и Linux в ответ на некоторую ситуацию, получив сообщение о котором процесс, в свою очередь, может предпринять какое-то действие. Мы применяем термин «возбуждать» (raise) для обозначения генерации сигнала и термин «захватывать» (catch) для обозначения получения или приема сигнала. Сигналы возбуждаются некоторыми ошибочными ситуациями, например нарушениями сегментации памяти, ошибками процессора при выполнении операций с плавающей точкой или некорректными командами. Они генерируются командной оболочкой и обработчиками терминалов для вызова прерываний и могут явно пересылаться от одного процесса к другому как способ передачи информации или коррекции поведения. Во всех этих случаях программный интерфейс один и тот же. Сигналы могут возбуждаться, улавливаться и соответственно обрабатываться или (по крайней мере, некоторые) игнорироваться.

Имена сигналов задаются с помощью включенного заголовочного файла signal.h. Они начинаются с префикса SIG и включают приведенные в табл. 11.3 сигналы.

Таблица 11.3

SIGABORT	*Процесс аварийно завершается
SIGALRM	Сигнал тревоги
SIGFPE	*Исключение операции с плавающей точкой
SIGHUP	Неожиданный останов или разъединение
SIGILL	*Некорректная команда
SIGINT	Прерывание терминала
SIGKILL	Уничтожение (не может быть перехвачен или игнорирован)
SIGPIPE	Запись в канал без считывателя
SIGQUIT	Завершение работы терминала
SIGSEGV	*Некорректный доступ к сегменту памяти
SIGTERM	Завершение, выход
SIGUSR1	Сигнал 1, определенный пользователем
SIGUSR2	Сигнал 2, определенный пользователем

*Могут быть также предприняты действия, зависящие от конкретной реализации.

Если процесс получает один из этих сигналов без предварительной подготовки к его перехвату, процесс будет немедленно завершен. Обычно при этом создается файл с дампом ядра. Этот файл в текущем каталоге, названный core, представляет собой образ процесса, который может оказаться полезным при отладке.

К дополнительным относятся сигналы, приведенные в табл. 11.4.

Таблица 11.4

SIGCHLD	Дочерний процесс остановлен или завершился
SIGCONT	Продолжить выполнение, если процесс был приостановлен
SIGSTOP	Остановить выполнение (не может захватываться или игнорироваться)
SIGTSTP	Сигнал останова, посылаемый с терминала
SIGTTIN	Фоновый процесс пытается читать
SIGTTOU	Фоновый процесс пытается писать

Сигнал SIGCHLD может быть полезен для управления дочерними процессами. По умолчанию он игнорируется. Остальные сигналы заставляют процессы, получившие их, остановиться, за исключением сигнала SIGCONT, который вызывает возобновление процесса. Они применяются программами командной оболочки для контроля работы и редко используются в пользовательских программах.

Чуть позже мы рассмотрим более подробно первую группу сигналов. Пока же достаточно знать, что если командная оболочка и драйвер терминала нормально настроены, ввод символа прерывания (обычно от нажатия комбинации клавиш +) с клавиатуры приведет к отправке сигнала SIGINT приоритетному процессу, т.е. программе, выполняющейся в данный момент. Это вызовет завершение программы, если в ней не предусмотрен перехват сигнала,

Если вы хотите отправить сигнал не текущей приоритетной задаче, а другому процессу, используйте команду kill. Она принимает для отправки процессу в качестве необязательного параметра имя сигнала или его номер и PID (который, как правило, можно определить с помощью команды ps). Например, для отправки сигнала «останов или разъединение» командной оболочке, выполняющейся на другом терминале с PID 512, вы должны применить следующую команду:

$ kill -HUP 512

Удобный вариант команды kill – команда killall, которая позволяет отправить сигнал всем процессам, выполняющим конкретную команду. Не все системы UNIX поддерживают ее, но ОС Linux, как правило, поддерживает. Этот вариант полезен, когда вы не знаете PID процесса или хотите отправить сигнал нескольким разным процессам, выполняющим одну и ту же команду. Обычное применение – заставить программу inetd перечитать параметры настройки. Для этого можно воспользоваться следующей командой:

$ killall -HUP inetd

Программы могут обрабатывать сигналы с помощью библиотечной функции signal.

#include

void (*signal(int sig, void (*func)(int)))(int);

Это довольно сложное объявление говорит о том, что signal – это функция, принимающая два параметра, sig и func. Сигнал, который нужно перехватить или игнорировать, задается аргументом sig. Функция, которую следует вызвать при получении заданного сигнала, содержится в аргументе func. Эта функция должна принимать единственный аргумент типа int (принятый сигнал) и иметь тип void. Функция сигнала возвращает функцию того же типа, которая является предыдущим значением функции, заданной для обработки сигнала, или одно из двух специальных значений:

□ SIG_IGN – игнорировать сигнал;

□ SIG_DFL – восстановить поведение по умолчанию.

Пример сделает все понятным. В упражнении 11.7 вы напишете программу ctrlc.c, которая реагирует на нажатие комбинации клавиш + вместо обычного завершения выводом соответствующего сообщения. Повторное нажатие + завершает программу.

Упражнение 11.7. Обработка сигнала

Функция ouch реагирует на сигнал, передаваемый в параметре sig. Эта функция будет вызываться, когда возникнет сигнал. Она выводит сообщение и затем восстанавливает обработку сигнала по умолчанию для сигнала SIGINT (генерируется при нажатии комбинации клавиш +).

#include

#include

#include

void ouch(int sig) {

 printf(«OUCH! – I got signal %dn», sig);

 (void)signal(SIGINT, SIG_DFL);

}

Функция main должна взаимодействовать с сигналом SIGINT, генерируемым при нажатии комбинации клавиш +. В остальное время она находится в бесконечном цикле, выводя один раз в секунду сообщение.

int main() {

 (void)signal(SIGINT, ouch);

 while(1) {

  printf(«Hello World!n»);

  sleep(1);

 }

}

Ввод комбинации клавиш + (отображается как ^C в следующем далее выводе) в первый раз заставляет программу отреагировать и продолжиться. Когда вы нажимаете + снова, программа завершается, т.к. сигнал SIGINT вернул программе стандартное поведение, заставляющее ее завершиться.

$ ./ctrlcl

Hello World!

Hello World!

Hello World!

Hello World!

^C

OUCH! – I got signal 2

Hello World!

Hello World!

Hello World!

Hello World!

^C

$

Как видно из данного примера, функция обработки сигнала принимает один целочисленный параметр – номер сигнала, приводящий к вызову функции. Это удобно, если одна и та же функция применяется для обработки нескольких сигналов. В данном случае вы выводите значение SIGINT, которое в этой системе оказывается равным 2. Не стоит полагаться на стандартные числовые значения сигналов, в новых программах всегда пользуйтесь именами сигналов.

Примечание

Вызывать из обработчика сигнала все функции, например, printf, небезопасно. Удобный метод – использовать флаг, устанавливаемый в обработчике сигнала, и затем проверять этот флаг в функции main и выводить сообщение, если нужно. В конце этой главы вы найдете список вызовов, которые можно безопасно применять в теле обработчиков сигналов.

Как это работает

Программа устроена так, что, когда вы задаете сигнал SIGINT, нажимая комбинацию клавиш +, вызывает функцию ouch. После того как функция прерывания ouch завершится, программа продолжает выполняться, но восстанавливает реакцию на сигнал, принятую по умолчанию. (У разных версий UNIX, в особенности у потомков системы Berkeley UNIX, в течение многих лет сложилось разное поведение при получении сигналов. Если вы хотите восстановить поведение по умолчанию после возникновения сигнала, лучше всего запрограммировать его на конкретные действия.) Когда программа получает второй сигнал SIGINT, она выполняет стандартное действие, приводящее к завершению программы.

Если вы хотите сохранить обработчик сигнала и продолжать реагировать на комбинацию клавиш +, вам придется восстановить его, вызвав функцию signal еще раз. Это приведет к возникновению короткого промежутка времени, начиная с запуска функции прерывания и до момента восстановления обработчика сигнала, в течение которого сигнал не будет обрабатываться. Если второй сигнал будет получен в этот период, вопреки вашим желаниям программа может завершиться.

Примечание

Мы не рекомендуем вам пользоваться функцией signal для перехвата сигналов. Мы включили ее в книгу, потому что она будет часто встречаться в более старых программах. Позже вы увидите sigaction, более четко определенный и надежный интерфейс, который следует применять в новых программах.

Функция signal возвращает предыдущее значение обработчика для заданного типа сигнала, если таковой есть, или в противном случае SIG_ERR с установкой положительного значения в переменной errno. Если задан неверный сигнал или делается попытка обработать сигнал, который не может быть перехвачен или игнорироваться, например SIGKILL, переменной errno присваивается значение EINVAL.