Нужно ли включать обработчики сигналов в каждый возможный контекст процесса?

Question

Например:

Скажем, у меня есть обработчик сигнала в main (), который обрабатывает сигнал таймера.У меня также есть рабочие потоки, которые создает main, у которых нет этого обработчика сигнала, потому что логика, необходимая для сигнала, содержится в main.Я полагаю, что это будет проблемой, потому что, если один из рабочих потоков в данный момент выполняется при отправке сигнала, он будет перехватывать сигнал и не будет иметь необходимого обработчика сигнала для его обработки.Но кажется излишним включать определения каждого отдельного соответствующего пользовательского обработчика сигнала в каждый возможный контекст.Я что-то упустил?

Answer 1

Скажем, у меня есть обработчик сигнала в main (), который обрабатывает тревогу по таймеру.

Нет, нет.Обработчик сигнала - это функция, и C не имеет осмысленного смысла, в котором одна функция может находиться внутри другой.

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

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

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

Не обязательно, и нет.

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

Но также нет, отдельные потоки не имеют отдельных обработчиков сигналов в любом случае, как я уже обсуждал.У каждого потока есть все обработчики сигналов, которые есть у процесса, потому что они принадлежат процессу, а не отдельным потокам.

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

Да.Я не уверен, какие именно детали вам не хватает, но смотрите выше.

Answer 2

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

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

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

Некоторые сигналы по своей природе специфичны для потоков (например, исключения с плавающей запятой и нарушения сегментации).Для получения дополнительной информации см. Справочную страницу signal(7).