Здравствуйте.
Есть обработчик сигнала, который устанавливается при помощи sigaction c флагом SA_RESTART

static struct sembuf        bsem_eactv[2] = {
                                             {0, 1,IPC_NOWAIT},
                                             {2, 1,IPC_NOWAIT}
                                            }; // [?/?/?]->[?+1/?/?+1]
void handle_signal(unsigned int signal_id)
{
semopt(ykernel.sem_id,bsem_eactv,0x2); //Activate core
}

причем сигнал нигде не блокируется. Вопрос, можно ли утверждать, что счетчик семафора (предполагается, что он не может переполниться) будет содержать точное число сгенерированных сигналов, на которые запущен обработчик? Или существует вероятность потери количества сгенерированных сигналов?

ОС - Линукс.
Спасибо.

• буферизация сигнала в Linux,Аноним, 12:19 , 24-Июл-08
  • буферизация сигнала в Linux,ghost_in_machine, 12:44 , 25-Июл-08
  • буферизация сигнала в Linux,const, 21:11 , 06-Авг-08
    • буферизация сигнала в Linux,ghost_in_machine, 11:24 , 07-Авг-08
      • буферизация сигнала в Linux,Аноним, 23:53 , 07-Авг-08
    • буферизация сигнала в Linux,Аноним, 23:51 , 07-Авг-08
      • буферизация сигнала в Linux,const, 17:08 , 13-Авг-08

>Вопрос, можно ли утверждать, что счетчик семафора
>(предполагается, что он не может переполниться) будет содержать точное число сгенерированных
>сигналов, на которые запущен обработчик? Или существует вероятность потери количества сгенерированных
>сигналов?
>
>ОС - Линукс.

Если сигналы не Real-time то могут потеряться (если одновременно сигнал придёт 2 раза обработчик будет вызван только 1 раз).

Используй Real-time сигналы, у них очереди ;)

>[оверквотинг удален]
>>(предполагается, что он не может переполниться) будет содержать точное число сгенерированных
>>сигналов, на которые запущен обработчик? Или существует вероятность потери количества сгенерированных
>>сигналов?
>>
>>ОС - Линукс.
>
>Если сигналы не Real-time то могут потеряться (если одновременно сигнал придёт 2
>раза обработчик будет вызван только 1 раз).
>
>Используй Real-time сигналы, у них очереди ;)

Спасибо

>Если сигналы не Real-time то могут потеряться (если одновременно сигнал придёт 2
>раза обработчик будет вызван только 1 раз).
>
>Используй Real-time сигналы, у них очереди ;)

man sigaction:

SA_NODEFER
    If set and sig is caught, sig shall not be added to the thread's signal mask on entry to the signal handler unless it is included in sa_mask. Otherwise, sig shall always be added to the thread's signal mask on entry to the signal handler.

Таким образом, чтобы не потерять сигналы, нужно лишь _не_ включать флаг SA_NODEFER ;)

Правда, очередь не резиновая и если вдруг каким-то чудом одномоментно придёт миллион сигналов, то часть всё же потеряется. Подозреваю, и RT сигналы не спасут от такого невезения.

>[оверквотинг удален]
>the signal handler unless it is included in sa_mask. Otherwise, sig
>shall always be added to the thread's signal mask on entry
>to the signal handler.
>
>Таким образом, чтобы не потерять сигналы, нужно лишь _не_ включать флаг SA_NODEFER
>;)
>
>Правда, очередь не резиновая и если вдруг каким-то чудом одномоментно придёт миллион
>сигналов, то часть всё же потеряется. Подозреваю, и RT сигналы не
>спасут от такого невезения.

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

>Простите, ваше предположение об очереди НЕ риал-таймовых сигналов проверено?

Нет там никаких очередей точно! Очереди только для RT. Размер очереди настраивается.

>SA_NODEFER
>    If set and sig is caught, sig shall
>not be added to the thread's signal mask on entry to
>the signal handler unless it is included in sa_mask. Otherwise, sig
>shall always be added to the thread's signal mask on entry
>to the signal handler.
>
>Таким образом, чтобы не потерять сигналы, нужно лишь _не_ включать флаг SA_NODEFER
>;)

Ты специально путаешь челевека? Здесь написано про ситуацию, когда обработчик сигнала вызывается после разблокирования сигнала, если сигнал пришёл в тот момент, когда он был заблокирован.

Соответственно этот флаг указывает что нужно делать: потерять сигнал или ждать пока он разблокируется и вызвать обработчик.

>Ты специально путаешь челевека? Здесь написано про ситуацию, когда обработчик сигнала вызывается
>после разблокирования сигнала, если сигнал пришёл в тот момент, когда он
>был заблокирован.
>
>Соответственно этот флаг указывает что нужно делать: потерять сигнал или ждать пока
>он разблокируется и вызвать обработчик.

Путаю не специально :)
Эксперименты показали следующее:

Для RT-сигналов есть очередь, для обычных - нет (эффект такой же, как если бы длина очереди была 1). Очередь используется для _заблокированных_ сигналов.

Не потерять сигналы можно двумя способами:
1. Использовать RT-сигнал (без флага SA_NODEFER: тогда обработчик для очередного сигнала будет вызван после того, как завершится обработчик предыдущего).
2. Установить флаг SA_NODEFER: тогда обработчик будет вызываться сразу, в момент появления сигнала. И возможно, будет прерывать сам себя, поэтому на совести приложения остаётся корректная работа :) Есть подозрение, что handle_signal из первого сообщения будет работать правильно.