Сигналы для межпроцессного взаимодействия

 

«ЭТО УЖАСНАЯ МЫСЛЬ! СИГНАЛЫ НЕ ПРЕДНАЗНАЧЕНЫ ДЛЯ ЭТОГО! Просто скажите НЕТ».

‑ Джефф Колье (Geoff Collyer) ‑

 

Одним из главных механизмов межпроцессного взаимодействия (IPC) являются каналы, которые описаны в разделе 9.3 «Базовая межпроцессная коммуникация каналы и FIFO». Сигналы также можно использовать для очень простого IPC[111]. Это довольно грубо; получатель может лишь сказать, что поступил определенный сигнал. Хотя функция позволяет получателю узнать PID и владельца процесса, пославшего сигнал, эти сведения обычно не очень помогают.

 

ЗАМЕЧАНИЕ. Как указывает цитата в начале, использование сигналов для IPC почти всегда является плохой мыслью. Мы рекомендуем по возможности избегать этого. Но нашей целью является научить вас, как использовать возможности Linux/Unix, включая их отрицательные моменты, оставляя за вами принятие информированного решения, что именно использовать.

 

Сигналы в качестве IPC для многих программ могут быть иногда единственным выбором. В частности, каналы не являются альтернативой, если две взаимодействующие программы не запущены общим родителем, а файлы FIFO могут не быть вариантом, если одна из взаимодействующих программ работает лишь со стандартными вводом и выводом. (Примером обычного использования сигналов являются определенные системные программы демонов, таких, как, которые принимают несколько сигналов, уведомляющих, что нужно повторно прочесть файл настроек, осуществить проверку непротиворечивости и т.д. См. xinetd (8) в системе GNU/Linux и inetd (8) в системе Unix.)

Типичная высокоуровневая структура основанного на сигналах приложения выглядит таким образом:

 

Ожидание сигнала

Обработка сигнала

 

Оригинальным интерфейсом V7 для ожидания сигнала является:

 

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

Проблема в только что описанной высокоуровневой структуре приложения кроется в части «Обработка сигнала». Когда этот код запускается, вы не захотите обрабатывать другой сигнал; вы хотите завершить обработку текущего сигнала до перехода к следующему. Одним из возможных решений является структурирование обработчика сигнала таким образом, что он устанавливает флаг и проверяет его в главном цикле:

 

 

В основном коде флаг проверяется:

 

К сожалению, этот код изобилует условиями гонки:

 

Решением является блокирование интересующего сигнала в любое время, кроме ожидания его появления. Например, предположим, что интересующим нас сигналом является:

 

 

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

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

При наличии всего этого не следует в новом коде использовать. был стандартизован POSIX главным образом для поддержки старого кода. То же самое верно и для функции System V Release 3. Вместо этого, если нужно структурировать свое приложение с использованием сигналов для IPC, используйте исключительно функции API и.

 

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

 

 

Важные сигналы специального назначения

 

Некоторые сигналы имеют особое назначение. Здесь мы опишем наиболее важные.

 

Сигнальные часы:, и

 

Часто бывает необходимо написать программу в виде

некоторое неверное условие

подождать некоторое время

 

Часто такая потребность возникает в сценариях оболочки, например, в ожидании регистрации определенного пользователя:

 

 

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