Арнольд Роббинс - Linux программирование в примерах

• Название: Linux программирование в примерах
• Автор: Арнольд Роббинс
• Издательство: Кудиц-Образ
• Жанр: Программное обеспечение
• Год: 2005
• ISBN: 5-9579-0059-1

В книге рассмотрены вопросы, связанные с программированием под Linux: файловый ввод/вывод, метаданные файлов, основы управления памятью, процессы и сигналы, пользователи и группы, вопросы интернационализации и локализации, сортировка, поиск и многие другие. Много внимания уделено средствам отладки, доступным под GNU Linux. Все темы иллюстрируются примерами кода, взятого из V7 UNIX и GNU. Эта книга может быть полезна любому, кто интересуется программированием под Linux.

---

Некоторые системы определяют также и другие сигналы, такие, как SIGEMT, SIGLOST и SIGINFO. Справочная страница GNU/Linux signal(7) предоставляет полный список; если ваша программа должна обработать сигналы, не поддерживаемые GNU/Linux, это можно сделать с помощью #ifdef:

#ifdef SIGLOST

/* ...обработать здесь SIGLOST... */

#endif

За исключением SIGSTKFLT, сигналы, перечисленные в табл. 10.1, широкодоступны и не нуждаются в заключении в #ifdef.

Сигналы SIGKILL и SIGSTOP нельзя перехватить или игнорировать (или блокировать, как описано далее в главе). Они всегда выполняют действие по умолчанию, указанное в табл. 10.1.

Чтобы увидеть список поддерживаемых сигналов, вы можете использовать 'kill -l'. На одной из наших систем GNU/Linux:

$ kill -l

 1) SIGHUP       2) SIGINT       3) SIGQUIT      4) SIGILL

 5) SIGTRAP      6) SIGABRT      7) SIGBUS       8) SIGFPE

 9) SIGKILL     10) SIGUSR1     11) SIGSEGV     12) SIGUSR2

13) SIGPIPE     14) SIGALRM     15) SIGTERM     17) SIGCHLD

18) SIGCONT     19) SIGSTOP     20) SIGTSTP     21) SIGTTIN

22) SIGTTOU     23) SIGURG      24) SIGXCPU     25) SIGXFSZ

26) SIGVTALRM   27) SIGPROF     28) SIGWINCH    29) SIGIO

30) SIGPWR      31) SIGSYS      32) SIGRTMIN    33) SIGRTMIN+1

34) SIGRTMIN+2  35) SIGRTMIN+3  36) SIGRTMIN+4  37) SIGRTMIN+5

38) SIGRTMIN+6  39) SIGRTMIN+7  40) SIGRTMIN+8  41) SIGRTMIN+9

42) SIGRTMIN+10 43) SIGRTMIN+11 44) SIGRTMIN+12 45) SIGRTMIN+13

46) SIGRTMIN+14 47) SIGRTMIN+15 48) SIGRTMAX-15 49) SIGRTMAX-14

50) SIGRTMAX-13 51) SIGRTMAX-12 52) SIGRTMAX-11 53) SIGRTMAX-10

54) SIGRTMAX-9  55) SIGRTMAX-8  56) SIGRTMAX-7  57) SIGRTMAX-6

58) SIGRTMAX-5  59) SIGRTMAX-4  60) SIGRTMAX-3  61) SIGRTMAX-2

62) SIGRTMAX-1  63) SIGRTMAX

Сигналы SIGRTXXX являются сигналами реального времени, сложная тема, которую мы не будем рассматривать.

10.3.2. Программная отправка сигналов: raise()

Помимо внешнего генерирования, сигнал может быть отправлен непосредственно самой программой с использованием стандартной функции С raise():

#include <signal.h> /* ISO С */

int raise(int sig);

Эта функция посылает сигнал sig вызывающему процессу. (Это действие имеет свое применение; вскоре мы увидим пример.)

Поскольку raise() определена стандартом С, для процесса это наиболее переносимый способ отправить себе сигнал. Есть другие способы, которые мы обсудим далее в главе.

10.4. Обработчики сигналов в действии

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

10.4.1. Традиционные системы

После помещения на место обработчика сигнала ваша программа развивается своим путем. Интересные вещи возникают лишь с появлением сигнала (например, пользователь нажал CTRL-C для прерывания вашей программы, или был сделан вызов raise()).

По получении сигнала ядро останавливает процесс, где бы он ни был. Затем оно имитирует вызов процедуры обработчика сигнала, передавая ему номер сигнала в качестве ее единственного аргумента. Ядро устраивает все таким образом, что нормальный возврат из функции обработчика сигнала (либо посредством return, либо в результате выпадения из конца функции) передает управление в ту точку программы, в которой она находилась в момент появления сигнала.

Что происходит после обработки сигнала, когда тот же самый сигнал появится в следующий раз снова? Остается ли обработчик на том же месте? Или же он сбрасывается, и для сигнала используется действие по умолчанию? Ответ, по историческим причинам, «зависит от». В частности, стандарт С оставляет это на усмотрение реализации.

На практике V7 и традиционные системы System V, такие, как Solaris, устанавливают для сигнала действие по умолчанию.

Давайте рассмотрим простой обработчик сигнала в действии под Solaris. Следующая программа, ch10-catchint.c, перехватывает SIGINT. Обычно вы генерируете этот сигнал, набирая на клавиатуре CTRL-C.

1  /* ch10-catchint.c - перехват SIGINT, по крайней мере, однажды. */

2

3  #include <signal.h>

4  #include <string.h>

5  #include <unistd.h>

6

7  /* handler --- простой обработчик сигнала. */

8

9  void handler(int signum)

10 {

11  char buf[200], *cp;

12  int offset;

13

14  /* Пройти через это испытание , чтобы избежать fprintf(). */

15  strcpy(buf, "handler: caught signal ");

16  cp = buf + strlen(buf); /* cp указывает на завершающий '\0' */

17  if (signum > 100) /* маловероятно */

18   offset = 3;

19  else if (signum > 10)

20   offset = 2;

21  else

22   offset = 1;

23  cp += offset;

24

25  *cp-- = '\0'; /* завершить строку */

26  while (signum >0) { /* work backwards, filling in digits */

27   *cp-- = (signum % 10) + '0';

28   signum /= 10;

29  }

30  strcat(buf, "\n");

31  (void)write(2, buf, strlen(buf));

32 }

33

34 /* main --- установить обработку сигнала и войти в бесконечный цикл */

35

36 int main(void)

37 {

38  (void)signal(SIGINT, handler);

39

40  for(;;)

41   pause(); /* ждать сигнал, см. далее в главе */

42

43  return 0;

44 }

Строки 9–22 определяют функцию обработки сигнала (остроумно названную handler()[106]). Все, что эта функция делает, — выводит номер перехваченного сигнала и возвращается. Для вывода этого сообщения она выполняет множество ручной работы, поскольку fprintf() не является «безопасной» для вызова из обработчика сигнала. (Вскоре это будет описано в разделе 10.4.6 «Дополнительные предостережения».)

Функция main() устанавливает обработчик сигнала (строка 38), а затем входит в бесконечный цикл (строки 40–41). Вот что происходит при запуске:

$ ssh solaris.example.com

 /* Зарегистрироваться на доступной системе Solaris */

Last login: Fri Sep 19 04:33:25 2003 from 4.3.2.1.

Sun Microsystems Inc. SunOS 5.9 Generic May 2002

$ gcc ch10-catchint.c /* Откомпилировать программу */

$ a.out /* Запустить ее */

^C handler: caught signal 2 /* Набрать ^C, вызывается обработчик */

^C /* Попробовать снова, но на этот раз... */

$ /* Программа завершается */

Поскольку V7 и другие традиционные системы восстанавливают действие сигнала по умолчанию, поэтому когда вы хотите снова получить сигнал в будущем, функция обработчика должна немедленно переустановить саму себя:

void handler(int signum) {

 char buf[200], *cp;

 int offset;

 (void)signal(signum, handler); /* переустановить обработчик */

 /* ...оставшаяся часть функции как прежде... */

}

10.4.2. BSD и GNU/Linux

BSD 4.2 изменила способ работы signal().[107] На системах BSD обработчик сигнала после его возвращения остается на месте. Системы GNU/Linux следуют поведению BSD. Вот что происходит под GNU/Linux:

$ ch10-catchint          /* Запустить программу */

handler: caught signal 2 /* Набираем ^C, вызывается обработчик */

handler: caught signal 2 /* И снова... */

handler: caught signal 2 /* И снова! */

handler: caught signal 2 /* Помогите! */

handler: caught signal 2 /* Как нам это остановить?! */

Quit (core dumped)       /* ^\, генерирует SIGQUIT. Bay */

На системе BSD или GNU/Linux обработчик сигнала не должен дополнительно использовать 'signal(signum, handler)' для переустановки обработчика. Однако, лишний вызов не причиняет никакого вреда, поэтому сохраняется статус-кво.

В действительности, POSIX предоставляет функцию bsd_signal(), которая идентична signal() за тем исключением, что она гарантирует, что обработчик сигнала останется установленным:

#include <signal.h> /* XSI, устаревает */

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

Это устраняет проблемы переносимости. Если вы знаете, что ваша программа будет работать лишь на системах POSIX, вы можете воспользоваться bsd_signal() вместо signal().

Одно предостережение — эта функция также помечена как «устаревающая», что означает возможность отказа от нее в будущем стандарте. На практике, даже если от нее откажутся, поставщики скорее всего долгое время будут ее поддерживать. (Как мы увидим, функция API POSIX sigaction() предоставляет достаточно возможностей для написания рабочей версии, если это вам нужно.)

10.4.3. Игнорирование сигналов

Более практично, когда вызывается обработчик сигнала, это означает, что программа должна завершиться и выйти. Было бы раздражающим, если бы большинство программ по получении SIGINT выводили бы сообщение и продолжали работу; смысл сигнала в том, что они должны остановиться!