Зомби — это процесс, который завершился, но не был удален. Удаление зомби возлагается на родительский процесс. Функция wait()
тоже это делает, поэтому перед ее вызовом не нужно проверять, продолжает ли выполняться требуемый дочерний процесс. Предположим, к примеру, что программа создает дочерний процесс, выполняет нужные вычисления и затем вызывает функцию wait()
. Если к тому времени дочерний процесс еще не завершился, функция wait()
заблокирует программу. В противном случае процесс на некоторое время превратится в зомби. Тогда функция wait()
извлечет код его завершения, система удалит процесс и функция немедленно завершится.
Что же всё-таки случится, если родительский процесс не удалит своих потомков? Они останутся в системе в виде зомби. Программа, показанная в листинге 3.6, порождает дочерний процесс, который немедленно завершается, тогда как родительский процесс берет минутную паузу, после чего тоже заканчивает работу, так и не позаботившись об удалении потомка.
Листинг 3.6. ( zombie.c ) Создание процесса-зомби
#include «stdlib.h>
#include
#include
int main() {
pid_t child_pid;
/* Создание дочернего процесса. */
child_pid = fork();
if (child_pid > 0) {
/* Это родительский процесс — делаем минутную паузу. */
sleep(60);
} else {
/* Это дочерний процесс — немедленно завершаем работу. */
exit(0);
}
return 0;
}
Скомпилируйте этот файл и запустите программу. Пока программа работает, перейдите в другое окно и просмотрите список процессов с помощью следующей команды:
% ps -е -o pid,ppid,stat,cmd
Эта команда отображает идентификатор самого процесса и его предка, а также статус процесса и его командную строку. Обратите внимание на присутствие двух процессов с именем zombie
. Один из них — предок, другой — потомок. У последнего идентификатор родительского процесса равен идентификатору основного процесса zombie
, при этом потомок обозначен как (несуществующий), а его код состояния равен Z (т.е. zombie — зомби).
Итак, мы хотим узнать, что будет, когда программа zombie
завершится, не вызвав функцию wait()
. Останется ли процесс-зомби? Нет — выполните команду ps
и убедитесь в этом: оба процесса zombie
исчезли. Дело в том, что после завершения программы управление ее дочерними процессами принимает на себя специальный процесс — демон init
, который всегда работает, имея идентификатор 1 (это первый процесс, запускаемый при загрузке Linux). Демон init
автоматически удаляет все унаследованные им дочерние процессы-зомби.
3.4.4. Асинхронное удаление дочерних процессов
Если дочерний процесс просто вызывает другую программу с помощью функции exec()
, то в родительском процессе можно сразу же вызвать функцию wait()
и пассивно дожидаться завершения потомка. Но очень часто нужно, чтобы родительский процесс продолжал выполняться одновременно с одним или несколькими своими потомками. Как в этом случае получать сигналы об их завершении?
Один подход заключается в периодическом вызове функции wait3()
или wait4()
. Функция wait()
в данной ситуации не подходит, так как в случае отсутствия завершившегося дочернего процесса она заблокирует основную программу. А вот упомянутые две функции принимают дополнительный флаг WNOHANG
, переводящий их в неблокируемый режим, в котором функция либо удаляет дочерний процесс, если он есть, либо просто завершается. В первом случае возвращается идентификатор процесса, во втором — 0.
Более элегантный подход состоит в асинхронном уведомлении родительского процесса о завершении потомка. Существуют разные способы сделать это, но проще всего воспользоваться сигналом SIGCHLD
, посылаемым как раз тогда, когда завершается дочерний процесс. По умолчанию программа никак не реагирует на этот сигнал, поэтому раньше вы могли и не знать о его существовании.
Таким образом, нужно организовать удаление дочерних процессов в обработчике сигнала SIGCHLD
. Естественно, код состояния удаляемого процесса следует сохранять в глобальной переменной, если эта информация необходима основной программе. В листинге 3.7 показана программа, в которой реализована данная методика.
Листинг 3.7. ( sigchld.c ) Удаление дочерних процессов в обработчике сигнала SIGCHLD
#include
#include
Читать дальше