Читаем Linux программирование в примерах полностью

Linux программирование в примерах

`_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()`

10.4.7. Наша история до настоящего времени, эпизод 1

Сигналы являются сложной темой, и она становится еще более сбивающей с толку. Поэтому давайте на время сделаем остановку, сделаем шаг назад и подведем итог обсужденному до сих пор:

• Сигналы являются указанием того, что произошло некоторое внешнее событие.

• 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() для простых программ достаточно, и он все еще широко используется.