PARENT: finished!
# CHILD: signal unblock
received signal 56 code = -2 val = 0
received signal 56 code = -2 val = 1
received signal 56 code = -2 val = 2
received signal 55 code = -2 val = 0
received signal 55 code = -2 val = 1
received signal 55 code = -2 val = 2
received signal 54 code = -2 val = 0
received signal 54 code = -2 val = 1
received signal 54 code = -2 val = 2
Первый сюрприз, который нас ожидает, — это общее количество сигналов реального времени, выводимое программой в первой строке. Документация (HELP QNX) утверждает:
There are 24 POSIX 1003.1b realtime signals, including:
SIGRTMIN — First realtime signal.
SIGRTMAX — Last realtime signal.
Здесь есть некоторое несоответствие: тест дает значения констант SIGRTMIN = 41 и SIGRTMAX = 56, а общее количество сигналов = 16 (POSIX, как вы помните, требует минимум 8). «Потерявшиеся» сигналы (24 – 16 = 8), очевидно, и есть те сигналы из диапазона 32…40, которые выходят за пределы общих UNIX-сигналов (1…31), но не отнесены к диапазону сигналов реального времени (41…56).
Но гораздо больший сюрприз состоит в порядке доставки сигналов из очереди FIFO принимающему процессу. Документация об этом сообщает (выделено нами):
The POSIX standard includes the concept of queued realtime signals. QNX Neutrino supports optional queuing of any signal, not just realtime signals. The queuing can be specified on a signal-by-signal basis within a process. Each signal can have an associated 8-bit code and a 32-bit value.
This is very similar to message pulses described earlier. The kernel takes advantage of this similarity and uses common code for managing both signals and pulses. The signal number is mapped to a pulse priority using SIGMAX — signo. As a result, signals are delivered in priority order with lower signal numbers having higher priority. This conforms with the POSIX standard, which states that existing signals have priority over the new realtime signals.
Изменим временной порядок возбуждения сигналов - от сигналов с меньшими номерами к сигналам с большими номерами:
# ./s5 -b54 -e56 -n2
signal SIGRTMIN=41 - signal SIGRTMAX=56
CHILD: signal mask set
signal sent: 54 with val = 0
signal sent: 54 with val = 1
signal sent: 55 with val = 0
signal sent: 55 with val = 1
signal sent: 56 with val = 0
signal sent: 56 with val = 1
PARENT: finished!
# CHILD: signal unblock
received signal 56 code = -2 val = 0
received signal 56 code = -2 val = 1
received signal 55 code = -2 val = 0
received signal 55 code = -2 val = 1
received signal 54 code = -2 val = 0
received signal 54 code = -2 val = 1
Независимо от порядка отправки сигналов порядок доставки их из очереди принимающему процессу сохраняется от старших номеров сигналов, которые являются более приоритетными, к младшим. А это в точности противоположно тому, что обещает документация, и соответствует картине, которую У. Стивенс наблюдал в ОС Sun Solaris 2.6 и которую он же комментирует словами: «Похоже, что в реализации Solaris 2.6 есть ошибка».
Выполним ту же задачу, но теперь не относительно сигналов диапазона реального времени, а относительно стандартных UNIX-сигналов. Выберем для этого произвольный диапазон сигналов (<signal.h>):
#define SIGVTALRM 28 /* virtual timer expired */
#define SIGPROF 29 /* profiling timer expired */
#define SIGXCPU 30 /* exceeded cpu limit */
#define SIGXFSZ 31 /* exceeded file size limit */
Посмотрим результат в этом случае:
# ./s5 -b28 -e31 -n2
signal SIGRTMIN=41 - signal SIGRTMAX=56
CHILD: signal mask set
signal sent: 28 with val = 0
signal sent: 28 with val = 1
signal sent: 29 with val = 0
signal sent: 29 with val = 1
signal sent: 30 with val = 0
signal sent: 30 with val = 1
signal sent: 31 with val = 0
signal sent: 31 with val = 1
PARENT finished!
# CHILD signal unblock
received signal 31 code = -2 val = 0
received signal 31 code = -2 val = 1
received signal 30 code = -2 val = 0
received signal 30 code = -2 val = 1
received signal 29 code = -2 val = 0
received signal 29 code = -2 val = 1
received signal 28 code = -2 val = 0
received signal 28 code = -2 val = 1
QNX при установке обработчика с флагом SA_SIGINFO использует модель работы реального времени не только относительно сигналов диапазона SIGRTMIN...SIGRTMAX, но и для всего множества стандартных UNIX- сигналов. Это расширение, впрочем, не противоречит приведенному выше утверждению POSIX, что такое решение факультативно (см. пункт 9 описания модели сигналов реального времени) и оставляется на усмотрение разработчика ОС.
Любопытным может оказаться и рассмотрение реакции на сигналы, которые никак не определены в QNX (в исследуемый диапазон для сравнения включены как неопределенные, так и определенные сигналы системы):
# ./s5 -b39 -e41 -n2
signal SIGRTMIN=41 - signal SIGRTMAX=56
