форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы Программирование под UNIX (Public)
Изначальное сообщение		[ Отслеживать ]

"буферизация сигнала в Linux"

Сообщение от ghost_in_machine on 22-Июл-08, 16:00

Здравствуйте. Есть обработчик сигнала, который устанавливается при помощи 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 } причем сигнал нигде не блокируется. Вопрос, можно ли утверждать, что счетчик семафора (предполагается, что он не может переполниться) будет содержать точное число сгенерированных сигналов, на которые запущен обработчик? Или существует вероятность потери количества сгенерированных сигналов? ОС - Линукс. Спасибо.

Высказать мнение | Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "буферизация сигнала в Linux"

Сообщение от Аноним (??) on 24-Июл-08, 12:19

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	2. "буферизация сигнала в Linux"
	Сообщение от ghost_in_machine on 25-Июл-08, 12:44
	>[оверквотинг удален] >>(предполагается, что он не может переполниться) будет содержать точное число сгенерированных >>сигналов, на которые запущен обработчик? Или существует вероятность потери количества сгенерированных >>сигналов? >> >>ОС - Линукс. > >Если сигналы не Real-time то могут потеряться (если одновременно сигнал придёт 2 >раза обработчик будет вызван только 1 раз). > >Используй Real-time сигналы, у них очереди ;) Спасибо
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	3. "буферизация сигнала в Linux"
	Сообщение от const (??) on 06-Авг-08, 21:11
	>Если сигналы не 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 сигналы не спасут от такого невезения.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	4. "буферизация сигнала в Linux"
	Сообщение от ghost_in_machine on 07-Авг-08, 11:24
	>[оверквотинг удален] >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 сигналы не >спасут от такого невезения. Спасибо за ответ. Простите, ваше предположение об очереди НЕ риал-таймовых сигналов проверено? Из мануала (мне) совершенно не ясно иметься в виду гарантированная доставка сигналов количественно или качественно. Собственно предполагал сам, и писали во взаимодействии процессов исключительно о гарантии качественной доставки. Не могли бы вы прояснить этот момент, спасибо.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	6. "буферизация сигнала в Linux"
	Сообщение от Аноним (??) on 07-Авг-08, 23:53
	>Простите, ваше предположение об очереди НЕ риал-таймовых сигналов проверено? Нет там никаких очередей точно! Очереди только для RT. Размер очереди настраивается.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	5. "буферизация сигнала в Linux"
	Сообщение от Аноним (??) on 07-Авг-08, 23:51
	>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 >;) Ты специально путаешь челевека? Здесь написано про ситуацию, когда обработчик сигнала вызывается после разблокирования сигнала, если сигнал пришёл в тот момент, когда он был заблокирован. Соответственно этот флаг указывает что нужно делать: потерять сигнал или ждать пока он разблокируется и вызвать обработчик.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	7. "буферизация сигнала в Linux"
	Сообщение от const (??) on 13-Авг-08, 17:08
	>Ты специально путаешь челевека? Здесь написано про ситуацию, когда обработчик сигнала вызывается >после разблокирования сигнала, если сигнал пришёл в тот момент, когда он >был заблокирован. > >Соответственно этот флаг указывает что нужно делать: потерять сигнал или ждать пока >он разблокируется и вызвать обработчик. Путаю не специально :) Эксперименты показали следующее: Для RT-сигналов есть очередь, для обычных - нет (эффект такой же, как если бы длина очереди была 1). Очередь используется для _заблокированных_ сигналов. Не потерять сигналы можно двумя способами: 1. Использовать RT-сигнал (без флага SA_NODEFER: тогда обработчик для очередного сигнала будет вызван после того, как завершится обработчик предыдущего). 2. Установить флаг SA_NODEFER: тогда обработчик будет вызываться сразу, в момент появления сигнала. И возможно, будет прерывать сам себя, поэтому на совести приложения остаётся корректная работа :) Есть подозрение, что handle_signal из первого сообщения будет работать правильно.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить	Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]