Есть ли способ сделать условно-прерывистые сигналы только для внутренних процессов?

Question

Я ищу способ, изнутри обработчика сигнала, условно прервать системный вызов таким образом, который происходит во время обработки сигнала.Для того, чтобы сделать это, предположим, что вызов read выполняется, и SIGRT0 получено.Этот обработчик сигнала использует SA_RESTART, потому что он не хочет безоговорочно прерывать системные вызовы, но в зависимости от условия я хочу, чтобы read возвращал EINTR сразу после возвращения обработчика сигнала.

В одну сторонуЯ мог бы сделать это, настроив другой обработчик сигнала для SIGRT1, поместив SIGRT1 в маску сигнала для обработчика SIGRT0 и исключив SA_RESTART из обработчика SIGRT1.Затем обработчик для SIGRT0 может raise SIGRT1, а когда возвращается первый, не прерывающийся обработчик сигнала, запускается второй, и read прерывается.

Проблема с этим решениемчто другие процессы могут отправлять SIGRT1, вызывая нежелательные EINTR вхождения.

Есть ли какой-нибудь способ добиться результата, который я ищу?

Answer 1

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

Возможно, что еще более важно, любая попытка прерывать системные вызовы с помощью EINTR преднамеренно подчиняется условиям гонки, когда сигнал поступает непосредственно перед системным вызовом блокировки, но после любой проверкипредотвратил бы системный вызов из-за того, что получил сигнал.Единственный раз, когда это может быть приемлемо, - это когда вы готовы запустить несколько сигналов с увеличивающимися задержками между ними, пока не будет удовлетворен «запрос на прерывание», но это входит в сферу хакерских взломов ...

Answer 2

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