форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

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

"Процессы"
Сообщение от Kornfan on 20-Янв-05, 13:17  (MSK)
Если процессу одновременно посылается несколько сигналов, ядро обрабатывает их в том порядке, в каком они перечислены в описании. Существуют три способа реагирования на получение сигнала - прием сигналов, завершение выполнения со сбросом на внешний носитель (дампированием) образа процесса в памяти и завершение выполнения без дампирования. Можно ли указать наилучший порядок обработки одновременно поступающих сигналов? Например, если процесс получает сигнал о выходе (вызывающий дампирование образа процесса в памяти) и сигнал о прерывании (выход без дампирования), то какой из этих сигналов имело бы смысл обработать первым?
	Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

Индекс форумов | Темы | Пред. тема | След. тема

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

1. "Процессы"
Сообщение от Dead Mustdie on 20-Янв-05, 13:43  (MSK)
>Если процессу одновременно посылается несколько сигналов, >ядро обрабатывает их в том порядке, в каком они перечислены в >описании. IMHO не совсем правда. Цитата из SUSv3: "When multiple unblocked signals, all in the range SIGRTMIN to SIGRTMAX, are pending, the behavior shall be as if the implementation delivers the pending unblocked signal with the lowest signal number within that range. No other ordering of signal delivery is specified." Упорядочивание, таким образом, производится по номерам сигналов. >Существуют три способа реагирования на получение сигнала - прием >сигналов, завершение выполнения со сбросом на внешний носитель >(дампированием) образа процесса в памяти и завершение выполнения >без дампирования. >Можно ли указать наилучший порядок обработки одновременно >поступающих сигналов? Например, если процесс получает сигнал о >выходе (вызывающий дампирование образа процесса в памяти) >и сигнал о прерывании (выход без дампирования), то какой из этих >сигналов имело бы смысл обработать первым? Указать может только само ядро, в рамках собственной реализации доставки сигналов. С точки зрения экономии системных ресурсов имело бы смысл первым (и единственным) обработать сигнал, обрывающий работу программы. Поскольку само его наличие обычно означает, что корректное продолжение работы программы невозможно.
Удалить	Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

	2. "Процессы"
	Сообщение от klalafuda on 20-Янв-05, 14:32  (MSK)
	>IMHO не совсем правда. Цитата из SUSv3: > >"When multiple unblocked signals, all in the range SIGRTMIN to >SIGRTMAX, are pending, the behavior shall be as if the >implementation delivers the pending unblocked signal with the >lowest signal number within that range. No other ordering of >signal delivery is specified." > >Упорядочивание, таким образом, производится по номерам сигналов. ммм.. какая-то imho странная сортировка :-/ например, в POSIX это просто FIFO: http://www.opengroup.org/onlinepubs/009695399/functions/sigaction.html ---cut--- If SA_SIGINFO is not set in sa_flags, then the disposition of subsequent occurrences of sig when it is already pending is implementation-defined; the signal-catching function shall be invoked with a single argument. If the implementation supports the Realtime Signals Extension option, and if SA_SIGINFO is set in sa_flags, then subsequent occurrences of sig generated by sigqueue() or as a result of any signal-generating function that supports the specification of an application-defined value (when sig is already pending) shall be queued in FIFO order until delivered or accepted; the signal-catching function shall be invoked with three arguments. The application specified value is passed to the signal-catching function as the si_value member of the siginfo_t structure. ---cut--- // wbr
	Удалить	Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

	3. "Процессы"
	Сообщение от DeadMustdie (??) on 20-Янв-05, 19:33  (MSK)
	> >ммм.. какая-то imho странная сортировка :-/ например, в POSIX >это просто FIFO: > > >http://www.opengroup.org/onlinepubs/009695399/functions/sigaction.html > Всё в точности как и в SUSv3. Просто оная FIFO действует при соблюдении следующих условий (как и указано в приведённом Вами фрагменте): 1. поддержка RSE 2. наличие установленного флага SA_SIGINFO 3. сигнал был сгенерирован sigqueue() либо функцией, позволяющей задать определённое приложением значение.
	Удалить	Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема

Пожалуйста, прежде чем написать сообщение, ознакомьтесь с данными рекомендациями.