_Exit() | fpathconf() | raise() | sigqueue() |
_exit() | fstat() | read() | sigset() |
accept() | fsync() | readlink() | sigsuspend() |
access() | ftruncate() | recv() | sleep() |
aio_error() | getegid() | recvfrom() | socket() |
aio_return() | geteuid() | recvmsg() | socketpair() |
aio_suspend() | getgid() | rename() | stat() |
alarm() | getgroups() | rmdir() | sysmlink() |
bind() | getpeername() | select() | sysconf() |
cfgetispeed() | getpgrp() | sem_post() | tcdrain() |
cfgetospeed() | getpid() | send() | tcflow() |
cfsetispeed() | getppid() | sendmsg() | tcflush() |
cfsetospeed() | getsockname() | sendto() | tcgetattr() |
chdir() | getsockopt() | setgid() | tcgetpgrp() |
chmod() | getuid() | setpgid() | tcsendbreak() |
chown() | kill() | setsid() | tcsetattr() |
clock_gettime() | link() | setsockopt() | tcsetpgrp() |
close() | listen() | setuid() | time() |
connect() | lseek() | shutdown() | timer_getoverrun() |
creat() | lstat() | sigaction() | timer_gettime() |
dup() | mkdir() | sigaddset() | timer_settime() |
dup2() | mkfifo() | sigdelset() | times() |
execle() | open() | sigemptyset() | umask() |
execve() | pathconf() | sigfillset() | uname() |
fchmod() | pause() | sigismember() | unlink() |
fchown() | pipe() | signal() | utime() |
fcntl() | poll() | sigpause() | wait() |
fdatasync() | posix_trace_event() | sigpending() | waitpid() |
fork() | pselect() | sigprocmask() | write() |
Сигналы являются сложной темой, и она становится еще более сбивающей с толку. Поэтому давайте на время сделаем остановку, сделаем шаг назад и подведем итог обсужденному до сих пор:
• Сигналы являются указанием того, что произошло некоторое внешнее событие.
• raise() является функцией ISO С для отправки сигнала
• signal() контролирует диспозицию сигнала, т.е. реакцию процесса на сигнал, когда он появляется. Сигнал можно оставить системе для обработки по умолчанию, проигнорировать или перехватить.
• Когда сигнал перехватывается, вызывается функция-обработчик. Вот где сложность начинает поднимать свою безобразную голову:
• ISO С не определяет, восстанавливается ли диспозиция сигнала по умолчанию до вызова обработчика или она остается на месте. Первое является поведением V7 и современных систем System V, таких, как Solaris. Последнее является поведением BSD, используемым также в GNU/Linux. (Для форсирования поведения BSD может использоваться функция POSIX bsd_signal().)
• То, что случается при прерывании сигналом системного вызова, также различается в традиционной и BSD линейках. Традиционные системы возвращают -1 с errno, установленным в EINTR. BSD системы повторно запускают системный вызов после возвращения из обработчика. Макрос GLIBC TEMP_FAILURE_RETRY() может помочь вам написать код для обработки системных вызовов, возвращающих -1 с errno, установленным в EINTR.
POSIX требует, чтобы частично выполненный системный вызов возвращал успешное завершение, указав, сколько работы было выполнено. Системный вызов, который еще не начал выполняться, вызывается повторно.
• Механизм signal() предоставляет плодотворную почву для появления условий гонки. В этой ситуации помогает тип данных ISO С sig_atomic_t, но он не решает проблему, и определенный таким способом механизм не может обезопасить от проявления условий гонки.
• Применяется ряд дополнительных предостережений, и в частности, из обработчика сигнала
Несмотря на эти проблемы интерфейса signal() для простых программ достаточно, и он все еще широко используется.
