Книга: Разработка приложений в среде Linux. Второе издание
10.4.2. Наблюдение за уничтожением дочерних процессов
10.4.2. Наблюдение за уничтожением дочерних процессов
Сбор состояний возврата дочернего процесса называется ожиданием процесса. Это можно делать четырьмя способами, хотя только один из вызовов предоставляется ядром. Остальные три метода реализованы в стандартной библиотеке С. Поскольку системный вызов ядра принимает четыре аргумента, он называется wait4()
.
pid_t wait4(pid_t pid, int *status, int options, struct rusage *rusage);
Первый аргумент, pid
, представляет собой процесс, код возврата которого должен быть возвращен. Он может принимать ряд специальных значений.
pid < -1
Ожидать завершения любого дочернего процесса, чей pgid равен абсолютному значению pid
.
pid = -1
Ожидать прерывания любого дочернего процесса.
pid = 0
Ожидать завершения дочернего из той же группы процессов, что и текущий[20].
Ожидать выхода процесса
pid > 0 pid
.
Второй параметр — это указатель на целое, которое устанавливается в значение, равное соду возврата того процесса, который заставляет wait4()
вернуть управление (мы будем зазывать его "проверяемым" процессом). Формат возвращенного состояния довольно закрученный, и для того, чтобы сделать его осмысленным, существует набор макросов.
Три события заставляют wait4()
вернуть состояние проверяемого процесса. Процесс может завершиться, он может быть прерван вызовом kill()
(получит фатальный сигнал) либо он может быть остановлен по какой-либо причине[21]. Вы можете узнать, что именно случилось, с помощью описанных ниже макросов, каждый из которых принимает возвращаемое состояние wait4()
в качестве единственного параметра.
WIFEXITED(status) |
Возвращает true , если процесс завершился нормально. Процесс завершается нормально, когда его функция main() выходит из программы посредством вызова exit() . Если WIFEXITED истинно, то WEXITSTATUS(status) возвращает код возврата процесса. |
WIFSIGNALED(status) |
Возвращает true , если процесс был прерван сигналом (это происходит, когда он прерывается вызовом kill() ). В этом случае WTERMSIG(status) возвращает номер сигнала, прервавшего процесс. |
WIFSTOPPED(status) |
Если процесс приостановлен сигналом, WIFSTOPPED() возвращает true , a WSTOPSIG(status) возвращает номер сигнала, приостановившего процесс. wait4() возвращает информацию только о приостановленных процессах, если указана опция WUNTRACED . |
Аргумент options
управляет поведением вызова. WHOHANG
заставляет функцию немедленно вернуть управление. Если в данный момент нет ни одного процесса, готового сообщить свое состояние, то возвращается 0 вместо допустимого pid. WUNTRACED
заставляет wait4()
возвратить соответствующий остановленный дочерний процесс. Более подробно о приостановленных процессах рассказывается в главе 15. Оба флажка могут быть объединены вместе битовой операцией "или".
Финальный параметр wait4()
, указатель на struct rusage
, наполняется информацией об использовании ресурсов проверяемым процессом и всеми его потомками. Более подробная информация об этом давалась при обсуждении getrusage()
и RUSAGE_BOTH
ранее в главе. Если этот параметр равен NULL
, информация о состоянии не возвращается.
Существуют три других интерфейса к wait4()
, каждый из которых представляет подмножество его функциональности.
pid_t wait(int *status) |
Единственный параметр wait() — это указатель на место, куда следует поместить код возврата прерванного процесса. Эта функция всегда блокирует выполнение до тех пор, пока дочерний процесс не будет прерван. |
pid_t waitpid (pid_t pid, int *status, int options) |
Функция waitpid() подобна wait4() . Единственное отличие в том, что она не возвращает информации об использовании ресурсов прерванным процессом. |
pid_t wait3(int *status, int options, struct rusage *rusage) |
Эта функция также подобна wait4() , но не позволяет специфицировать дочерний процесс, который должен быть проверен. |
- 10.4.6. Уничтожение других процессов
- 10.4. Примитивы процессов
- 10.4.1. Создание дочерних процессов
- Глава 7 Чего нужно опасаться при моделировании бизнес-процессов. Проектные риски моделирования бизнеспроцессов
- Эффективное взаимодействие процессов архитектуры Classic Server
- 1.2. Понятие информации. Общая характеристика процессов сбора, передачи, обработки и накопления информации
- 3.4.2. Остановка процессов
- 3.4.3. Просмотр процессов
- Лекция 16. Взаимодействие процессов
- 1.1.3. Уязвимости процессов накопления знаний (самообучения)
- 3.2. Создание процессов
- 3.3.2. Оценка информационной безопасности на основе модели зрелости процессов