Що відбувається з багатопотоковим процесом Linux, якщо він отримує сигнал?

Якщо процес Unix (Posix) отримує сигнал, обробляється сигнал.

Що буде з ним у багатопотоковому процесі? Яка нитка приймає сигнал?

На мою думку, API сигналу повинен бути розширений, щоб вирішити це (тобто, потік обробника сигналу повинен бути в змозі визначити), але для полювання на інформацію в мережі я знайшов лише цілий рік полум'я в списку розсилки Linux ядра та на різні форуми. Як я зрозумів, концепція Лінуса відрізнялася від стандарту Posix, і спочатку було побудовано якийсь шар compat, але тепер Linux слід за моделлю posix.

Який сучасний стан?

Запис у POSIX на тему " Генерація та доставка сигналів " у "Обгрунтування: Загальна інформація про системні інтерфейси"

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

З signal(7)посібника по системі Linux:

Сигнал може генеруватися (і, таким чином, очікувати) для процесу в цілому (наприклад, при надсиланні з використанням kill(2)) або для конкретної потоку (наприклад, певні сигнали, такі як SIGSEGV і SIGFPE, що генеруються як наслідок виконання певної машини- мовна інструкція спрямована на потоки, як і сигнали, спрямовані на певний потік із використанням pthread_kill(3)). Сигнал, орієнтований на процес, може бути доставлений до будь-якої з потоків, яка наразі не блокує сигнал. Якщо більше ніж один з потоків має сигнал розблокований, то ядро ​​вибирає довільну нитку, до якої подавати сигнал.

І в pthreads(7):

Нитки мають чіткі настройки альтернативного стека сигналу. Однак налаштування альтернативного стека сигналу нового потоку копіюються з потоку, який його створив, так що потоки спочатку поділяють альтернативний стек сигналу (зафіксований у ядрі 2.6.16).

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

Обробники сигналів, як правило, запускаються на стеку поточного виконавчого потоку.

(На даний момент я не знаю, як це обробляється, коли декілька потоків виконуються одночасно на багатопроцесорній машині)

Старіша реалізація потоків POSIX LinuxThread дозволяла націлювати лише окремі потоки по сигналах. З pthreads(7)системи Linux:

LinuxThreads не підтримує поняття про керовані процесом сигнали: сигнали можуть надсилатися лише певним потокам.