Что происходит с многопоточным процессом Linux, если он получает сигнал?

20

Если процесс Unix (Posix) получает сигнал, будет запущен обработчик сигнала.

Что будет с этим в многопоточном процессе? Какой поток получает сигнал?

На мой взгляд, API-интерфейс сигналов должен быть расширен, чтобы справиться с этим (то есть поток обработчика сигналов должен быть в состоянии быть определенным), но, ища информацию в сети, я обнаружил пламя на протяжении всего года в списке рассылки ядра Linux и в разные форумы. Как я понял, концепция Линуса отличалась от стандарта Posix, и сначала был создан некоторый уровень Compat, но теперь Linux следует модели Posix.

Каково текущее состояние?

linux signals posix multithreading Петер - Восстановить Монику
источник
3
Дубликат stackoverflow.com/questions/11679568/... «Pthreads (7) описывает , что POSIX.1 требует , чтобы все темы , доли атрибутов процесса, в том числе сигнальных диспозиции»
Стиву
@steve Спасибо, но 1) это на другом сайте SE 2) эта спецификация не уточняет, что именно произойдет. Что это значит, обработчики сигналов будут вызываться во всех потоках, но мне это кажется немного сюрреалистичным. 3) В этом ответе не указывается, какой была модель Линуса и почему / как она используется в настоящее время.
Петер - Восстановить Монику

Ответы:

9

Запись в POSIX « Генерация и доставка сигналов » в «Обоснование: общие сведения о системных интерфейсах» гласит:

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

Из signal(7)руководства по системе Linux:

Сигнал может быть сгенерирован (и, следовательно, ожидает рассмотрения) для процесса в целом (например, при отправке с использованием kill(2)) или для конкретного потока (например, определенных сигналов, таких как SIGSEGV и SIGFPE, сгенерированных как следствие выполнения конкретной машины). языковые инструкции ориентированы на потоки, как и сигналы, нацеленные на использование определенного потока pthread_kill(3)). Направленный на процесс сигнал может быть доставлен в любой из потоков, для которого в данный момент сигнал не заблокирован. Если более одного из потоков имеет разблокированный сигнал, то ядро ​​выбирает произвольный поток для доставки сигнала.

И в pthreads(7):

Потоки имеют различные альтернативные настройки стека сигналов. Однако настройки альтернативного стека сигналов нового потока копируются из потока, который его создал, так что изначально потоки совместно используют стек альтернативных сигналов (исправлено в ядре 2.6.16).

Из pthreads(3)руководства по системе OpenBSD (как пример альтернативного подхода):

Обработчики сигналов обычно выполняются в стеке текущего выполняющегося потока.

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

Более старая реализация LinuxThread потоков POSIX позволяла направлять сигналы только по отдельным потокам. Из pthreads(7)системы Linux:

LinuxThreads не поддерживает понятие процессов-ориентированных сигналов: сигналы могут отправляться только в определенные потоки.

Кусалананда
источник