Текст книги "UNIX: разработка сетевых приложений"

Теперь дочерний процесс находится в состоянии Z(зомби).

Процессы-зомби нужно своевременно удалять, а это требует работы с сигналами Unix. Поэтому в следующем разделе мы сделаем обзор управления сигналами, а затем продолжим рассмотрение нашего примера.

Сигнал– это уведомление процесса о том, что произошло некое событие. Иногда сигналы называют программными прерываниями( software interrupts). Подразумевается, что процесс не знает заранее о том, когда придет сигнал.

Сигналы могут посылаться в следующих направлениях:

■ одним процессом другому процессу (или самому себе);

■ ядром процессу.

Сигнал SIGCHLD, упомянутый в конце предыдущего раздела, ядро посылает родительскому процессу при завершении дочернего.

Для каждого сигнала существует определенное действие( actionили disposition– характер). Действие, соответствующее сигналу, задается с помощью вызова функции sigaction(ее описание следует далее) и может быть выбрано тремя способами:

1. Мы можем предоставить функцию, которая вызывается при перехвате определенного сигнала. Эта функция называется обработчиком сигнала( signal handler), а действие называется перехватыванием сигнала( catching). Сигналы SIGKILLи SIGSTOPперехватить нельзя. Наша функция вызывается с одним целочисленным аргументом, который является номером сигнала, и ничего не возвращает. Следовательно, прототип этой функции имеет вид:

void handler(int signo);

Для большинства сигналов вызов функции sigactionи задание функции, вызываемой при получении сигнала, – это все, что требуется для обработки сигнала. Но дальше вы увидите, что для перехватывания некоторых сигналов, в частности SIGIO, SIGPOLLи SIGURG, требуются дополнительные действия со стороны процесса.

2. Мы можем игнорироватьсигнал, если действие задать как SIG_IGN. Сигналы SIGKILLи SIGSTOPне могут быть проигнорированы.

3. Мы можем установить действие для сигнала по умолчанию, задав его как SIG_DFL. Действие сигнала по умолчанию обычно заключается в завершении процесса по получении сигнала, а некоторые сигналы генерируют копию области памяти процесса в его текущем каталоге (так называемый дамп– core dump). Есть несколько сигналов, для которых действием по умолчанию является игнорирование. Например, SIGCHLDи SIGURG(посылается по получении внеполосных данных, см. главу 24) – это два сигнала, игнорируемых по умолчанию, с которыми мы встретимся в тексте.

Согласно POSIX, чтобы определить действие для сигнала, нужно вызвать функцию sigaction. Однако это достаточно сложно, поскольку один аргумент этой функции – это структура, для которой необходимо выделение памяти и заполнение. Поэтому проще задать действие сигнала с помощью функции signal. Первый ее аргумент – это имя сигнала, а второй – либо указатель на функцию, либо одна из констант SIG_IGNи SIG_DFL. Но функция signalсуществовала еще до появления POSIX.1, и ее различные реализации имеют разную семантику сигналов с целью обеспечения обратной совместимости. В то же время POSIX четко диктует семантику при вызове функции sigaction. Это обеспечивает простой интерфейс с соблюдением семантики POSIX. Мы включили эту функцию в нашу собственную библиотеку вместе функциями err_ XXXи функциями-обертками, которые мы используем для построения всех наших программ. Она представлена в листинге 5.5. Функция-обертка Signalздесь не показана, потому что ее вид не зависит от того, какую именно функцию signalона должна вызывать.

Листинг 5.5. Функция signal, вызывающая функцию POSIX sigaction

//lib/signal.c

 1 #include "unp.h"

 2 Sigfunc*

 3 signal(int signo, Sigfunc *func)

 4 {

 5  struct sigaction act, oact;

 6  act.sa_handler = func;

 7  sigemptyset(&act.sa_mask);

 8  act.sa_flags = 0;

 9  if (signo == SIGALRM) {

10 #ifdef SA_INTERRUPT

11   act.sa_flags |= SA_INTERRUPT; /* SunOS 4.x */

12 #endif

13  } else {

14 #ifdef SA_RESTART

15   act.sa_flags |= SA_RESTART; /* SVR4, 44BSD */

16 #endif

17  }

18  if (sigaction(signo, &act, &oact) < 0)

19   return (SIG_ERR);

20  return (oact.sa_handler);

21 }

Упрощение прототипа функции при использовании typedef

2-3 Обычный прототип для функции signalусложняется наличием вложенных скобок:

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

Чтобы упростить эту запись, мы определяем тип Sigfuncв нашем заголовочном файле unp.hследующим образом:

typedef void Sigfunc(int);

указывая тем самым, что обработчики сигналов – это функции с целочисленным аргументом, ничего не возвращающие ( void). Тогда прототип функции выглядит следующим образом:

Sigfunc *signal(int signo, Sigfunc * func);

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

Установка обработчика

6 Элемент sa_handlerструктуры sigactionустанавливается равным аргументу funcфункции signal.

Установка маски сигнала для обработчика

7 POSIX позволяет нам задавать набор сигналов, которые будут блокированыпри вызове обработчика сигналов. Любой блокируемый сигнал не может быть доставлен процессу. Мы устанавливаем элемент sa_maskравным пустому набору. Это означает, что во время работы обработчика дополнительные сигналы не блокируются. POSIX гарантирует, что перехватываемый сигнал всегда блокирован, пока выполняется его обработчик.

Установка флага SA_RESTART

8-17 Флаг SA_RESTARTне является обязательным, и если он установлен, то системный вызов, прерываемый этим сигналом, будет автоматически снова выполнен ядром. (В продолжении нашего примера мы более подробно поговорим о прерванных системных вызовах.) Если перехватываемый сигнал не является сигналом SIGALRM, мы задаем флаг SA_RESTART, если таковой определен. (Причина, по которой сигнал SIGALRMобрабатывается отдельно, состоит в том, что обычно цель его генерации – ввести ограничение по времени в операцию ввода-вывода, как показано в листинге 14.2. В этом случае мы хотим, чтобы блокированный системный вызов был прерван сигналом.) Более ранние системы, особенно SunOS 4.x, автоматически перезапускают прерванный системный вызов по умолчанию и затем определяют флаг SA_INTERRUPT. Если этот флаг задан, мы устанавливаем его при перехвате сигнала SIGALRM.

Вызов функции sigaction

18-20 Мы вызываем функцию sigaction, а затем возвращаем старое действие сигнала как результат функции signal.

В книге мы везде используем функцию signalиз листинга 5.5.

Сведем воедино следующие моменты, относящиеся к обработке сигналов в системе, совместимой с POSIX.

■ Однажды установленный обработчик сигналов остается установленным (в более ранних системах обработчик сигналов удалялся каждый раз по выполнении).

■ На время выполнения функции – обработчика сигнала доставляемый сигнал блокируется. Более того, любые дополнительные сигналы, заданные в наборе сигналов sa_mask, переданном функции sigactionпри установке обработчика, также блокируются. В листинге 5.5 мы устанавливаем sa_maskравным пустому набору, что означает, что никакие сигналы, кроме перехватываемого, не блокируются.

■ Если сигнал генерируется один или несколько раз, пока он блокирован, то обычно после разблокирования он доставляется только один раз, то есть по умолчанию сигналы Unix не устанавливаются в очередь. Пример мы рассмотрим в следующем разделе. Стандарт POSIX реального времени 1003.1b определяет набор надежныхсигналов, которые помещаются в очередь, но в этой книге мы их не используем.

■ Существует возможность выборочного блокирования и разблокирования набора сигналов с помощью функции sigprocmask. Это позволяет нам защитить критическую область кода, не допуская перехватывания определенных сигналов во время ее выполнения.

Назначение состояния зомби – сохранить информацию о дочернем процессе, чтобы родительский процесс мог ее впоследствии получить. Эта информация включает идентификатор дочернего процесса, статус завершения и данные об использовании ресурсов (время процессора, память и т.д.). Если у завершающегося процесса есть дочерний процесс в зомбированном состоянии, идентификатору родительского процесса всех зомбированных дочерних процессов присваивается значение 1 (процесс init), что позволяет унаследовать дочерние процессы и сбросить их (то есть процесс initбудет ждать ( wait) их завершения, благодаря чему будут удалены зомби). Некоторые системы Unix в столбце COMMANDвыводят для зомбированных процессов значение .

Очевидно, что нам не хотелось бы оставлять процессы в виде зомби. Они занимают место в ядре, и в конце концов у нас может не остаться идентификаторов для нормальных процессов. Когда мы выполняем функцию forkдля дочерних процессов, необходимо с помощью функции waitдождаться их завершения, чтобы они не превратились в зомби. Для этого мы устанавливаем обработчик сигналов для перехватывания сигнала SIGCHLDи внутри обработчика вызываем функцию wait. (Функции waitи waitpidмы опишем в разделе 5.10.) Обработчик сигналов мы устанавливаем с помощью вызова функции

Signal(SIGCHLD, sig_chld);

в листинге 5.1, после вызова функции listen. (Необходимо сделать это до вызова функции forkдля первого дочернего процесса, причем только один раз.) Затем мы определяем обработчик сигнала – функцию sig_chld, представленную в листинге 5.6.

Листинг 5.6. Версия обработчика сигнала SIGCHLD, вызывающая функцию wait (усовершенствованная версия находится в листинге 5.8)

//tcpcliserv/sigchldwait.с

 1 #include "unp.h"

 2 void

 3 sig_chld(int signo)

 4 {

 5  pid_t pid;

 6  int stat;

 7  pid = wait(&stat);

 8  printf("child terrmnatedn", pid);

 9  return;

10 }

ВНИМАНИЕ

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

В системах System V и Unix 98 дочерний процесс не становится зомби, если процесс задает действие SIG_IGN для SIGCHLD. К сожалению, это верно только для System V и Unix 98. В POSIX прямо сказано, что такое поведение этим стандартом не предусмотрено. Переносимый способ обработки зомби состоит в том, чтобы перехватывать сигнал SIGCHLD и вызывать функцию wait или waitpid.

Если мы откомпилируем в Solaris 9 программу, представленную в листинге 5.1, вызывая функцию Signalс нашим обработчиком sig_chld, и будем использовать функцию signalиз системной библиотеки (вместо нашей версии, показанной в листинге 5.5), то получим следующее:

solaris % tcpserv02 &  запускаем сервер в фоновом режиме

[2] 16939

solaris % tcpcli01 127.0.0.1  затем клиент

hi there  набираем эту строку

hi there и она отражается сервером

^D       вводим символ конца файла

child 16942 terminated функция printf из обработчика сигнала выводит эту строку

accept error: Interrupted system call но функция main преждевременно прекращает выполнение

Последовательность шагов в этом примере такова:

1. Мы завершаем работу клиента, вводя символ EOF. TCP клиента посылает сегмент FIN серверу, и сервер отвечает сегментом ACK.

2. Получение сегмента FIN доставляет EOF ожидающей функции readlineдочернего процесса. Дочерний процесс завершается.

3. Родительский процесс блокирован в вызове функции accept, когда доставляется сигнал SIGCHLD. Функция sig_chld(наш обработчик сигнала) выполняется, функция waitполучает PID дочернего процесса и статус завершения, после чего из обработчика сигнала вызывается функция printf. Обработчик сигнала возвращает управление.

4. Поскольку сигнал был перехвачен родительским процессом, в то время как родительский процесс был блокирован в медленном(см. ниже) системном вызове (функция accept), ядро заставляет функцию acceptвозвратить ошибку EINTR(прерванный системный вызов). Родительский процесс не обрабатывает эту ошибку корректно (см. листинг 5.1), поэтому функция mainпреждевременно завершается.

Цель данного примера – показать, что при написании сетевых программ, перехватывающих сигналы, необходимо получать информацию о прерванных системных вызовах и обрабатывать их. В этом специфичном для Solaris 2.5 примере функция signalиз стандартной библиотеки С не осуществляет автоматический перезапуск прерванного вызова, то есть флаг SA_RESTART, установленный нами в листинге 5.5, не устанавливается функцией signal из системной библиотеки. Некоторые другие системы автоматически перезапускают прерванный системный вызов. Если мы запустим тот же пример в 4.4BSD, используя ее библиотечную версию функции signal, ядро перезапустит прерванный системный вызов и функция acceptне возвратит ошибки. Одна из причин, по которой мы определяем нашу собственную версию функции signalи используем ее далее, – решение этой потенциальной проблемы, возникающей в различных операционных системах (см. листинг 5.5).

Кроме того, мы всегда программируем явную функцию returnдля наших обработчиков сигналов (см. листинг 5.6), даже если функция ничего не возвращает ( void), чтобы этот оператор напоминал нам о возможности прерывания системного вызова при возврате из обработчика.