Сигналы, передающиеся через и

 

Когда программа вызывает, ситуация с сигналами в порожденном процессе почти идентична ситуации в родительском процессе. Установленные обработчики остаются на месте, заблокированные сигналы остаются заблокированными и т.д. Однако, любые ожидающие в родителе сигналы в потомке сбрасываются, включая установленный с помощью временной интервал. Это просто, и это имеет смысл.

Когда процесс вызывает одну из функций, положение в новой программе следующее:

• Сигналы с установленным действием по умолчанию остаются с этим действием по умолчанию.

• Все перехваченные сигналы сбрасываются в состояние с действием по умолчанию.

• Сигналы, которые игнорируются, продолжают игнорироваться. Особым случаем является. Если до вызова игнорировался, он может игнорироваться также и после вызова. В качестве альтернативы для него может быть восстановлено действие по умолчанию. То, что происходит на самом деле, стандартом POSIX намеренно не определяется. (Справочные страницы GNU/Linux не определяют, что делает Linux, и поскольку POSIX оставляет это не определенным, любой код, который вы пишете для использования, должен быть подготовлен для обработки любого случая.)

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

• Любые ожидающие сигналы (те, которые появились, но были заблокированы) сбрасываются. Новая программа не может их получить.

• Временной интервал, остающийся для, сохраняется на своем месте. (Другими словами, если процесс устанавливает, а затем непосредственно вызывает, новый образ в конечном счете получит. Если он сначала вызывает, родитель сохраняет установки, тогда как потомок, вызывающий, не сохраняет.

 

ЗАМЕЧАНИЕ. Многие, если не все. программы предполагают, что сигналы инициализированы действиями по умолчанию и что заблокированных сигналов нет. Таким образом, особенно если не вы писали программу, запускаемую с помощью, можно разблокировать перед вызовам все сигналы

 

 

Резюме

 

«Наша история до настоящего времени, эпизод III»

‑ Арнольд Роббинс (Arnold Robbins) ‑

 

• Интерфейсы обработки сигналов развились от простых, но подверженных состояниям гонок, до сложных, но надежных. К сожалению, множественность интерфейсов затрудняет их изучение по сравнению с другими API Linux/Unix.

• У каждого сигнала есть связанное с ним действие. Действие может быть одним из следующих: игнорирование сигнала; выполнение действия системы по умолчанию или вызов предоставленного пользователем обработчика. Действие системы по умолчанию, в свою очередь, является одним из следующих: игнорирование сигнала, завершение процесса; завершение процесса с созданием его образа; остановка процесса или возобновление процесса, если он остановлен.

• и стандартизованы ISO С. управляет действиями для определенных сигналов; посылает сигнал текущему процессу. Остаются ли обработчики сигналов установленными после вызова или сбрасываются для действия по умолчанию, зависит от реализации, и являются простейшими интерфейсами, для многих приложений их достаточно.

• POSIX определяет функцию, которая подобна, но гарантирует, что обработчик остается установленным.

• Действия, происходящие после возвращения из обработчика, варьируют в зависимости от системы. Традиционные системы (V7, Solaris, возможно, и другие) восстанавливают действие сигнала по умолчанию. На этих системах прерванный системный вызов возвращает ‑1, устанавливая в значение. Системы BSD оставляют обработчик установленным и возвращают ‑1 с, содержащим, лишь в случае, когда не было перемещения данных; в противном случае, системный вызов запускается повторно.

• GNU/Linux придерживается POSIX, который похож, но не идентичен с BSD. Если не было перемещения данных, системный вызов возвращает ‑1/. В противном случае он возвращает объем перемещенных данных. Поведение BSD «всегда повторный запуск» доступно через интерфейс, но он не является действием по умолчанию.

• Обработчики сигналов, используемые с, подвержены состояниям гонок. Внутри обработчиков сигналов должны использоваться исключительно переменные типа. (В целях упрощения в некоторых из наших примеров мы не всегда следовали этому правилу.) Таким же образом, для вызова из обработчика сигналов безопасными являются лишь функции из табл. 10.2.

• Первоначальной попыткой создания надежных сигналов был API сигналов System V Release 3 (скопированный из BSD 4.0). Не используйте его в новом коде.

• POSIX API содержит множество компонентов:

• маску сигналов процесса, перечисляющую текущие заблокированные сигналы;

• тип для представления масок сигналов, и функции,,, и для работы с ними;

• функцию для установки и получения маски сигналов процесса,

• функцию для получения набора ожидающих сигналов;

• API и во всем их великолепии.

Все эти возможности вместе используют блокирование сигналов и маску сигналов процесса для предоставления надежных сигналов. Более того, через различные флаги можно получить повторно запускаемые системные вызовы и более подходящие обработчики сигналов, которые получают большую информацию о причине, вызвавшей определенный сигнал (структура).

• Механизмами POSIX для посылки сигналов являются и. Они отличаются от в двух отношениях: (1) одни процесс может послать сигнал другому процессу или целой группе процессов (конечно, с проверкой прав доступа), и (2) посылка сигнала 0 ничего не посылает, но осуществляет проверку. Таким образом, эти функции предоставляют способ проверки наличия определенного процесса или группы процессов и возможность посылки ему (им) сигнала.

• Сигналы могут использоваться в качестве механизма IPC, хотя такой способ является плохим способом структурирования приложения, подверженным состояниям гонок. Если кто‑то держит приставленным к вашей голове ружье, чтобы заставить вас работать таким способом, для правильной работы используйте тщательное блокирование сигналов и интерфейс.

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

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

• Перехват позволяет родителю узнать, что делает порожденный им процесс. Использование '' (или с) вообще игнорирует потомков. Использование с предоставляет уведомления лишь о завершении. В последнем случае, независимо от того, заблокирован или нет, обработчики сигналов для должны быть готовы немедленно обработать несколько потомков. Наконец, использование без с обработчиком сигналов с тремя аргументами дает вам причину получения сигнала.

• После положение сигналов в порожденном процессе остается тем же самым, за исключением сброса ожидающих сигналов и установленных интервалов таймера. После положение несколько более сложно – в сущности, все, что может быть оставлено, остается; для всего остального восстанавливаются значения по умолчанию.

 

Упражнения

 

1. Реализуйте с использованием.

2. Если у вас не установлен GNU/Linux, запустите на своей системе. Является ли ваша система традиционной или BSD?

3. Реализуйте функции System V Release 3,,, и, использовав и другие подходящие функции из POSIX API.

4. Потренируйте свои навыки в жонглировании битами. В предположении, что сигнал 0 отсутствует и что имеется не более 31 сигналов, предусмотрите для и напишите,,, и.

5. Еще немного потренируйте свои навыки жонглирования битами. Повторите предыдущее упражнение, на этот раз предположив, что наибольшим сигналом является 42.

6. Теперь, когда вы сделали предыдущие два упражнения, найдите и др. в своем заголовочном файле. (Может потребоваться поискать их; они могут быть в файлах, указанных в.) Являются ли они макросами или функциями?

7. В разделе 10.7 «Сигналы для межпроцессного взаимодействия» мы упомянули, что код изделия должен работать с начальной маской сигналов процесса, добавляя и удаляя блокируемые сигналы в вызове. Перепишите пример, используя для этого соответствующие вызовы.

8. Напишите свою собственную версию команды. Интерфейс должен быть таким:

имя‑сигнала pid

Если сигнал не указан, программа должна посылать.

9. Как вы думаете, почему в современных оболочках, таких, как Bash и ksh93, является встроенной командой?

10. (Трудное) Реализуйте, используя, и. Что случится, если обработчик сигнала для уже установлен?

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

12. Попробуйте заставить испортить информацию в, и. Теперь добавьте вокруг критического раздела блокирование/разблокирование и посмотрите, есть ли разница.

 

 

Глава 11