Текст книги "Linux программирование в примерах"
Автор книги: Арнольд Роббинс
Жанры:
Программирование
,сообщить о нарушении
Текущая страница: 25 (всего у книги 55 страниц)
main()Программа может естественно завершиться одним из двух способов: посредством использования одной из описанных далее функций или возвратившись из main(). (Третий, более радикальный способ описан далее в разделе 12.4 «Совершение самоубийства: abort()».) В последнем случае следует использовать явное возвращаемое значение вместо выпадения в конце функции:
/* Правильно */ /* Неправильно */
int main(int argc, char **argv) int main(int argc, char **argv)
{ {
/* здесь код */ /* здесь код */
return 0; /* ?? Что возвращает main()? */
} }
Стандарт С 1999 г. указывает, что при выпадении в конце, поведение функции main() должно быть таким, как если бы она возвращала 0. (Это верно также для С++; однако, стандарт С 1989 г. намеренно оставляет этот случай неопределенным.) Во всех случаях плохо полагаться на это поведение; однажды вы можете программировать для системы со скудной поддержкой С времени исполнения, или для внедренной системы, или где-то еще, где это будет по-другому. (В общем, выпадение в конце любой функции, не являющейся void – плохая мысль, которая может вести лишь к ошибочному коду.)
Возвращенное из main() значение автоматически передается обратно системе, от которой родительский процесс может его впоследствии получить. Мы опишем, как это делается, в разделе 9.1.6.1 «Использование функций POSIX: wait() и waitpid()».
ЗАМЕЧАНИЕ. На системах GNU/Linux управляемая компилятором команда c99 запускает компилятор с соответствующими опциями, так что возвращаемое значение при выпадении из конца функции равно 0. Простой gcc этого не делает.
Другим способом естественного завершения программы является вызов функций завершения. Стандарт С определяет следующие функции:
#include
void exit(int status);
void _Exit(int status);
int atexit(void (*function)(void));
Эти функции работают следующим образом:
void exit(int status)
Эта функция завершает программу, status передается системе для использования родителем. Перед завершением программы exit() вызывает все функции, зарегистрированные с помощью atexit(), сбрасывает на диск и закрывает все открытые потоки <stdio.h> FILE* и удаляет все временные файлы, созданные tmpfile() (см. раздел 12.3.2 «Создание и открытие временных файлов»). Когда процесс завершается, ядро закрывает любые оставшиеся открытыми файлы (которые были открыты посредством open(), creat() или через наследование дескрипторов), освобождает его адресное пространство и освобождает любые другие ресурсы, которые он мог использовать. exit() никогда не возвращается.
void _Exit(int status)
Эта функция в сущности идентична функции POSIX _exit(); мы на короткое время отложим ее обсуждение,
int atexit(void (*function)(void))
function является указателем на функцию обратного вызова, которая должна вызываться при завершении программы, exit() запускает функцию обратного вызова перед закрытием файлов и завершением. Идея в том, что приложение может предоставить одну или более функций очистки, которые должны быть запущены перед окончательным завершением работы. Предоставление функции называется ее регистрацией. (Функции обратного вызова для nftw() обсуждались в разделе 8.4.3.2 «Функция обратного вызова nftw()»; здесь та же идея, хотя atexit() вызывает каждую зарегистрированную функцию лишь однажды.)
atexit() возвращает 0 при успехе или -1 при неудаче и соответствующим образом устанавливает errno.
Следующая программа не делает полезной работы, но демонстрирует, как работает atexit():
/* ch09-atexit.c – демонстрация atexit().
Проверка ошибок для краткости опущена. */
/*
* Функции обратного вызова здесь просто отвечают на вызов.
* В настоящем приложении они делали бы больше. */
void callback1(void) { printf("callback1 calledn"); }
void callback2(void) { printf("callback2 calledn"); }
void callback3(void) { printf("callback3 calledn"); }
/* main – регистрация функций и завершение */
int main(int argc, char **argv) {
printf("registering callback1n"); atexit(callback1);
printf("registering callback2n"); atexit(callback2);
printf("registering callback3n"); atexit(callback3);
printf("exiting nown");
exit(0);
}
Вот что происходит при запуске:
$ ch09-atexit
registering callback1 /* Запуск главной программы */
registering callback2
registering callback3
exiting now
callback3 called /* Функции обратного вызова запускаются в обратном
порядке */
callback2 called
callback1 called
Как показывает пример, функции, зарегистрированные с помощью atexit(), запускаются в порядке, обратном порядку их регистрации: последние первыми. (Это обозначается также LIFO – last-in-first-out – вошедший последним выходит первым).
POSIX определяет функцию _exit(). В отличие от exit(), которая вызывает функции обратного вызова и выполняет _exit() является «сразу заканчивающейся» функцией:
#include
void _exit(int status);
Системе передается status, как и для exit(), но процесс завершается немедленно. Ядро все еще делает обычную очистку: все открытые файлы закрываются, использованная адресным пространством память освобождается, любые другие ресурсы, использованные процессом, также освобождаются.
На практике функция _Exit() ISO С идентична _exit(). Стандарт С говорит, что от реализации функции зависит, вызывает ли _Exit() зарегистрированные atexit() функции и закрывает ли открытые файлы. Для систем GLIBC это не так, и функция ведет себя подобно _exit().
Время использовать _exit() наступает, когда exec в порожденном процессе завершается неудачей. В этом случае вам не нужно использовать обычный exit(), поскольку это сбрасывает на диск данные буферов, хранящиеся в потоках FILE*. Когда позже родительский процесс сбрасывает на диск свои копии буферов, данные буфера оказываются записанными дважды; это очевидно нехорошо.
Например, предположим, что вы хотите запустить команду оболочки и хотите сами выполнить fork и exec. Такой код выглядел бы следующим образом:
char *shellcommand = "...";
pid_t child;
if ((child = fork()) == 0) { /* порожденный процесс */
execl("/bin/sh", "sh", "-c", shellcommand, NULL);
_exit(errno == ENOENT ? 127 : 126);
}
/* родитель продолжает */
Проверка значения errno и завершающего значения следуют соглашениям, используемым оболочкой POSIX. Если запрошенная программа не существует (ENOENT – нет для неё элемента в каталоге), завершающее значение равно 127. В противном случае, файл существует, но exec не могла быть выполнена по какой-то другой причине, поэтому статус завершения равен 126. Хорошая мысль следовать этим соглашениям также и в ваших программах. Вкратце, чтобы хорошо использовать exit() и atexit(), следует делать следующее:
• Определить небольшой набор значений статуса завершения, которые ваша программа будет использовать для сообщения этой информации вызывающему. Используйте для них в своем коде константы #define или enum.
• Решить, имеет ли смысл наличие функций обратного вызова для использования с atexit(). Если имеет, зарегистрировать их в main() в соответствующий момент; например, после анализа опций и инициализации всех структур данных, которые функция обратного вызова должна очищать. Помните, что функции должны вызываться в порядке LIFO (последняя вызывается первой).
• Использовать exit() для выхода из программы во всех местах, когда что-то идет не так и когда выход является правильным действием. Используйте коды ошибок, которые определили.
• Исключением является main(), для которой можно использовать при желании return. Наш собственный стиль заключается обычно в использовании exit() при наличии проблем и 'return 0' в конце main(), если все прошло хорошо.
• Использовать _exit() или _Exit() в порожденном процессе, если exec() завершается неудачей.
Когда процесс заканчивается, нормальным ходом событий для ядра является освобождение всех его ресурсов. Ядро сохраняет статус завершения законченного процесса, также, как сведения о ресурсах, которые он использовал в своей работе, a PID продолжает считаться используемым. Такой завершившийся процесс называется зомби.
Родительский процесс, будь то первоначальный родитель или init, может получить статус завершения порожденного процесса. Или, посредством использования функций BDS, которые не стандартизованы POSIX, можно получить статус завершения вместе со сведениями об использовании ресурсов. Использование статуса осуществляется ожиданием окончания процесса: это известно также как пожинание (reaping) процесса[91]91
Мы это не придумываем. Терминология, конечно, не совсем правильна, но таким было чувство юмора разработчиков оригинальной Unix – Примеч. автора.
[Закрыть].
Между механизмами, которые ожидают завершения потомков, и сигнальными механизмами, которые мы еще не обсуждали, есть значительное взаимодействие. Что из них описать вначале представляет собой нечто вроде проблемы курицы и яйца; мы решили сначала поговорить сначала о механизмах ожидания порожденного процесса, а глава 10 «Сигналы» дает полный рассказ о сигналах.
Пока достаточно понять, что сигнал является способом уведомления процесса о том, что произошло некоторое событие. Процессы могут генерировать сигналы, которые посылаются самим себе, или сигналы могут посылаться извне другими процессами или пользователем за терминалом. Например, CTRL-C посылает сигнал «прерывания», a CTRL-Z посылает сигнал управления работой «стоп».
По умолчанию, многие сигналы, такие, как сигнал прерывания, заставляют получающий процесс закончиться. Другие, такие, как сигналы управления работами, вызывают изменение его состояния. Механизмы ожидания порожденного процесса могут определить, претерпел ли процесс сигнал завершения, и если да, какой это был сигнал. То же верно и для остановки процесса и, на некоторых системах возобновления процесса.
wait() и waitpid()Первоначальным системным вызовом V7 был wait(). Более новым вызовом POSIX, основанным на возможностях BSD, является waitpid(). Объявления функций следующие:
#include
#include
pid_t wait(int *status);
pid_t waitpid(pid_t pid, int *status, int options);
wait() ждет завершения любого порожденного процесса; сведения о том, как он завершился, возвращаются в *status. (Вскоре мы обсудим, как интерпретировать *status.) Возвращаемое значение является PID завершившегося процесса или -1, если возникла ошибка.
Если порожденных процессов нет, wait() возвращает -1 с errno, установленным в ECHILD (отсутствует порожденный процесс). В противном случае, функция ждет завершения первого порожденного процесса или поступления сигнала.
Функция waitpid() дает возможность ждать завершения определенного порожденного процесса. Она предоставляет значительную гибкость и является предпочтительной для использования функцией. Она также возвращает PID закончившегося процесса или -1 при возникновении ошибки. Аргументы следующие:
pid_t pid
Значение указывает, завершения какого порожденного процесса ждать как по-настоящему pid, так и по группе процесса. Смысл значения pid следующий:
pid < -1 Ждать завершения любого порожденного процесса с ID группы процесса, равной абсолютному значению pid.
pid = -1 Ждать завершения любого порожденного процесса. Таким способом работает wait().
pid = 0 Ждать завершения любого порожденного процесса с ID группы процесса, равной ID группе родительского процесса.
pid > 0 Ждать завершения конкретного процесса с PID, равным pid.
int *status
То же, что и для wait(). *status, которые мы вскоре опишем
int options
Этот параметр должен быть равен либо 0, либо побитовым ИЛИ одного или более из следующих флагов:
WNOHANG
Если ни один порожденный процесс не завершился, вернуться немедленно. Таким способом можно периодически проверять, не закончился ли какой– нибудь порожденный процесс. (Такая периодическая проверка известна как опрашивание события.)
WUNTRACED
Вернуть сведения о порожденном процессе, который остановился, но еще не завершился. (Например, для управления работой.)
WCONTINUED
(XSI.) Вернуть сведения о порожденном процессе, который продолжился, если его статус не сообщался с момента изменения. Это также для управления работой. Этот флаг является расширением XSI и не доступен под GNU/Linux.
С заполненным значением *status работают несколько макросов, определяющие, что случилось. Они имеют тенденцию образовывать пары: один макрос для определения, что что-то случилось, и если этот макрос истинен, еще один макрос позволяет получить подробности. Макросы следующие:
WIFEXITED(status)
Этот макрос не равен нулю (true), если процесс завершился (в противоположность изменению состояния).
WEXITSTATUS(status)
Этот макрос дает статус завершения; он равен восьми наименее значимым битам значения, переданного exit() или возвращенного из main(). Этот макрос следует использовать лишь если WIFEXIDED(status) равен true.
WIFSIGNALED(status)
Этот макрос не равен нулю, если процесс подвергся действию завершающего сигнала death-by-signal.
WTERMSIG(status)
Этот макрос предоставляет номер сигнала, который завершил процесс. Этот макрос следует использовать, лишь когда WIFSIGNALED(status) равен true.
WIFSTOPPED(status)
Этот макрос не равен нулю, если процесс был остановлен.
WSTOPSIG(status)
Этот макрос предоставляет номер сигнала, который остановил процесс. (Процесс остановить могут несколько сигналов.) Этот макрос следует использовать лишь когда WIFSTOPPED(status) равен true. Сигналы управления работами обсуждаются в разделе 10.8.2 «Сигналы управления работой».
WIFCONTINUED(status)
(XSI.) Этот макрос не равен нулю, если процесс был продолжен. Соответствующего макроса WCONTSIG() нет, поскольку лишь один сигнал может вызвать продолжение процесса.
Обратите внимание, что этот макрос является расширением XSI и в частности, он недоступен в GNU/Linux. Следовательно, если вы хотите его использовать, заключите код внутри '#ifdef WIFCONTINUED ... #endif'.
WCOREDUMP(status)
(Общий.) Этот макрос не равен нулю, если процесс создал снимок. Снимок процесса (core dump) является образом запущенного процесса в памяти, созданном при завершении процесса. Он предназначен для использования впоследствии при отладке. Системы Unix называют файл core, тогда как системы GNU/Linux используют corе.pid, где pid является ID завершившегося процесса. Определенные сигналы завершают процесс и автоматически создают снимок процесса.
Обратите внимание, что этот макрос не стандартный. Системы GNU/Linux, Solaris и BSD его поддерживают, однако некоторые другие системы Unix нет. Поэтому и здесь, если нужно его использовать, заключите код внутрь '#ifdef WCOREDUMP ... #endif'.
Большинство программ не интересуются, почему завершился порожденный процесс; им просто нужно, что он завершился, возможно, отметив, было завершение успешным или нет. Программа GNU Coreutils install демонстрирует такое простое использование fork(), execlp() и wait(). Опция -s заставляет install запустить для устанавливаемого двоичного исполняемого файла программу strip. (strip удаляет из исполняемого файла отладочную и прочую информацию. Это может сохранить значительное пространство. На современных системах с многогигабайтными жесткими дисками при установке редко бывает необходимо использовать strip для исполняемых файлов.) Вот функция strip() из install.с:
513 /* Вырезать таблицу имен из файла PATH.
514 Мы могли бы сначала вытащить из файла магическое число
515 для определения, нужно ли вырезать, но заголовочные файлы и
516 магические числа варьируют от системы к системе так сильно, что
517 сделать его переносимым было бы очень трудно. Не стоит усилий. */
518
519 static void
520 strip (const char *path)
521 {
522 int status;
523 pid_t pid = fork();
524
525 switch (pid)
526 {
527 case -1:
528 error(EXIT_FAILURE, errno, _("fork system call failed"));
529 break;
530 case 0: /* Порожденный. */
531 execlp("strip", "strip", path, NULL);
532 error(EXIT_FAILURE, errno, _("cannot run strip"));
533 break;
534 default: /* Родитель. */
535 /* Родительский процесс. */
536 while (pid != wait(&status)) /* Ждать завершения потомка. */
537 /* Ничего не делать. */ ;
538 if (status)
539 error(EXIT_FAILURE, 0, _("strip failed"));
540 break;
541 }
542 }
Строка 523 вызывает fork(). Затем оператор switch предпринимает нужное действие для возвращения ошибки (строки 527–529), порожденного процесса (строки 530–533) и родительского процесса (строки 534–539).
Стиль строк 536–537 типичен; они ожидают завершения нужного порожденного процесса. Возвращаемое значение wait() является PID этого потомка. Оно сравнивается с PID порожденного процесса, status проверяется лишь на предмет равенства нулю (строка 538), в случае ненулевого результата потомок завершился неудачно. (Тест, хотя и правильный, грубый, но простой. Более правильным был бы тест наподобие 'if (WIFEXITED(status) && WEXITSTATUS(status) != 0)'.)
Из описаний и кода, представленных до сих пор, может показаться, что родительские программы должны выбрать определенный момент, чтобы ожидать завершения любого порожденного процесса, возможно, с опросом в цикле (как делает install.c), ожидая всех потомков. В разделе 10.8.3 «Родительский надзор: три различные стратегии» мы увидим, что это необязательно. Скорее, сигналы предоставляют ряд механизмов для использования уведомлениями родителей о завершении порожденных процессов.
wait3() и wait4()Системные вызовы BSD wait3() и wait4() полезны, если вы интересуетесь ресурсами, использованными порожденным процессом. Функции нестандартны (что означает, что они не являются частью POSIX), но широко доступны, в том числе на GNU/Linux. Объявления следующие:
#include
#include
/* Под GNU/Linux не нужно, но улучшает переносимость */
#include
#include
pid_t wait3(int *status, int options, struct rusage *rusage);
pid_t wait4(pid_t pid, int *status, int options, struct rusage *rusage);
Переменная status та же, что и для wait() и waitpid(). Все описанные ранее макросы (WIFEXITED() и т.д.) могут использоваться и с ними.
Значение options также то же самое, что и для waitpid(): либо 0, либо побитовое ИЛИ с одним или обоими флагами WNOHANG и WUNTRACED.
wait3() ведет себя подобно wait(), получая сведения о первом доступном порожденном зомби, a wait4() подобна waitpid(), получая сведения об определенном процессе. Обе функции возвращают PID потомка, -1 при ошибке или 0, если нет доступных процессов и был использован флаг WNOHANG. Аргумент pid может принимать те же значения, что и аргумент pid для waitpid().
Ключевым отличием является указатель struct rusage. Если он не равен NULL, система заполняет ее сведениями о процессе. Эта структура описана в POSIX и в справочной странице getrusage(2):
struct rusage {
struct timeval ru_utime; /* используемое время пользователя */
struct timeval ru_stime; /* используемое системное время */
long ru_maxrss; /* максимальный размер резидентного набора */
long ru_ixrss; /* общий размер разделяемой памяти */
long ru_idrss; /* общий размер не разделяемых данных */
long ru_isrss; /* общий размер не разделяемого стека */
long ru_minflt; /* использование страниц */
long ru_majflt; /* ошибок страниц */
long ru_nswap; /* подкачек */
long ru_inblock; /* блочных операций ввода */
long ru_oublock; /* блочных операций вывода */
long ru_msgsnd; /* посланных сообщений */
long ru_msgrcv; /* полученных сообщений */
long ru_nsignals; /* полученных сигналов */
long ru_nvcsw; /* добровольных переключений контекста */
long ru_nivcsw; /* принудительных переключений контекста */
};
Чисто BSD системы (4.3 Reno и более поздние) поддерживают все поля. В табл. 9.2 описаны доступность различных полей struct rusage для POSIX и Linux.
Таблица 9.2. Доступность полей struct rusage
ru_utime | √ | ≥ 2.4 | ru_nswap | ≥2.4 | |
ru_stime | √ | ≥2.4 | ru_nvcsw | ≥2.6 | |
ru_minflt | ≥2.4 | ru_nivcsw | ≥2.6 | ||
ru_majflt | ≥2.4 |
Стандартом определены лишь поля, помеченные «POSIX». Хотя Linux определяет полную структуру, ядро 2.4 поддерживает лишь поля времени пользователя и системного времени. Ядро 2.6 поддерживает также поля, связанные с переключением контекста.[92]92
Дважды проверьте справочную страницу getrusage(2), если у вас более новое ядро, поскольку это поведение, возможно, изменилось – Примеч. автора.
[Закрыть]
Наиболее интересными полями являются ru_utime и ru_stime, использование времени процессора в режиме пользователя и ядра соответственно. (Время процессора в режиме пользователя является временем, потраченным на исполнение кода уровня пользователя. Время процессора в режиме ядра является временем, потраченным в ядре в пользу процесса.)
Эти два поля используют struct timeval, которая содержит значения времени с точностью до микросекунд. Дополнительные сведения по этой структуре см. в разделе 14.3.1 «Время в микросекундах: gettimeofday()».
В BSD 4.2 и 4.3 аргумент status функций wait() и wait3() был union wait. Он умещался в int и предоставлял доступ к тем же сведениям, которые выдают современные макросы WIFEXITED() и др., но через членов объединения. Не все члены были действительными во всех случаях. Эти члены и их использование описаны в табл. 9.3.
Таблица 9.3. union wait 4.2 и 4.3 BSD
WIFEXITED() | w_termsig | w.w_termsig == 0 | True при нормальном завершении |
WEXITSTATUS() | w_retcode | code = w.w_retcode | Статус завершения, если не по сигналу |
WIFSIGNALED() | w_termsig | w.w_temsig != 0 | True, если завершен по сигналу |
WTERMSIG() | w_termsig | sig = w.w_termsig | Сигнал, вызвавший завершение |
WIFSTOPPED() | w_stopval | w.w_stopval == WSTOPPED | True, если остановлен |
WSTOPSIG() | w_stopsig | sig = w.w_stopsig | Сигнал, вызвавший остановку |
WCOREDUMP() | w_coredump | w.w_coredump != 0 | True, если потомок сделал снимок образа |
POSIX не стандартизует union wait, a BSD 4.4 не документирует его, используя вместо этого макросы POSIX. GLIBC делает несколько бросков, чтобы заставить использующий его старый код продолжать работать. Мы опишем его здесь главным образом для того, чтобы вы увидев его – узнали; новый код должен использовать макросы, описанные в разделе 9.1.6.1 «Использование функций POSIX: wait() и waitpid()».
