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

• Процессы,Dead Mustdie, 13:43 , 20-Янв-05
  • Процессы,klalafuda, 14:32 , 20-Янв-05
    • Процессы,DeadMustdie, 19:33 , 20-Янв-05

>Если процессу одновременно посылается несколько сигналов,
>ядро обрабатывает их в том порядке, в каком они перечислены в
>описании.

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 не совсем правда. Цитата из 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/siga...

---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

>
>ммм.. какая-то imho странная сортировка :-/ например, в POSIX
>это просто FIFO:
>
>
>http://www.opengroup.org/onlinepubs/009695399/functions/siga...
>

Всё в точности как и в SUSv3. Просто оная FIFO действует при соблюдении
следующих условий (как и указано в приведённом Вами фрагменте):
1. поддержка RSE
2. наличие установленного флага SA_SIGINFO
3. сигнал был сгенерирован sigqueue() либо функцией, позволяющей
задать определённое приложением значение.