SIGRTMIN or SIGRTMAX – who’s higher up (in signal delivery priority order)?

Linux supports Realtime (RT) signals (part of the Posix IEEE 1003.1b [POSIX.1b Realtime] draft standard). The only other GPOS (General Purpose OS) that does so is Solaris (TODO- verify. Right? Anyone??).

The Linux RT signals can be seen with the usual ‘kill’ command (‘kill -l’; that’s the letter lowercase L).

[As can be seen from the command output, am running on an Ubuntu 15.10 Linux box, with glibc version 2.21]:

$ cat /etc/issue
Ubuntu 15.10 \n \l

$ uname -r
4.2.0-22-generic
$ 
$ ls -l /lib/x86_64-linux-gnu/libc-2.21.so
-rwxr-xr-x 1 root root 1869392 Mar 26  2015 /lib/x86_64-linux-gnu/libc-2.21.so*
$ 
$ kill -l
 1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP
 6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10) SIGUSR1
11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15) SIGTERM
16) SIGSTKFLT 17) SIGCHLD 18) SIGCONT 19) SIGSTOP 20) SIGTSTP
21) SIGTTIN 22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ
26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO 30) SIGPWR
31) SIGSYS 34) SIGRTMIN 35) SIGRTMIN+1 36) SIGRTMIN+2 37) SIGRTMIN+3
38) SIGRTMIN+4 39) SIGRTMIN+5 40) SIGRTMIN+6 41) SIGRTMIN+7 42) SIGRTMIN+8
43) SIGRTMIN+9 44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13
48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52) SIGRTMAX-12
53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9 56) SIGRTMAX-8 57) SIGRTMAX-7
58) SIGRTMAX-6 59) SIGRTMAX-5 60) SIGRTMAX-4 61) SIGRTMAX-3 62) SIGRTMAX-2
63) SIGRTMAX-1 64) SIGRTMAX 
$

RT (RealTime) signals above are highlighted in blue colour.

There is (was?) some confusion (different opinions in texts, manuals) as to the prioritization of queued RT signals; is SIGRTMIN the lowest priority signal (seems intuitive).

Turns out this is not the case (as I’ve empirically verified): the top priority RT signal is SIGRTMIN; the least (lowest) priority RT signal is SIGRTMAX.

Source: the man page on signal(7):

...

Real-time Signals
Linux supports real-time signals as originally defined in the POSIX.1b real-time extensions (and now included in  POSIX.1-2001).
The  range  of supported real-time signals is defined by the macros SIGRTMIN and SIGRTMAX.

...

Real-time signals are distinguished by the following:

1.  Multiple  instances  of real-time signals can be queued.  By contrast, if multiple instances of a standard signal are delivered while that signal is currently blocked, then only one instance is queued.

2.  If the signal is sent using sigqueue(3), an accompanying value (either an integer or a pointer) can be sent with the signal. If  the receiving process establishes a handler for this signal using the SA_SIGINFO flag to sigaction(2) then it can obtain this data via the si_value field of the siginfo_t structure passed as the second argument to the handler.  Furthermore,  the si_pid and si_uid fields of this structure can be used to obtain the PID and real user ID of the process sending the signal.

3.  Real-time  signals  are  delivered  in a guaranteed order.  Multiple real-time signals of the same type are delivered in the order they were sent.  If different real-time signals are sent to a process, they are delivered starting  with  the  lowest-numbered signal.  (I.e., low-numbered signals have highest priority.) By contrast, if multiple standard signals are pending for a process, the order in which they are delivered is unspecified.

If both standard and real-time signals are pending for a process, POSIX leaves it unspecified which is delivered first.   Linux, like many other implementations, gives priority to standard signals in this case.

So that settles it.

PS>
A related question that also pops up wrt RT signals: notice that the integer value of SIGRTMIN is 34, and not 32. Why?

... 31) SIGSYS 34) SIGRTMIN ...

Check out what the man page on signal(7) says:

The Linux kernel supports a range of 33 different real-time signals,
numbered 32 to 64.  However, the glibc POSIX threads implementation
internally uses two (for NPTL) or three (for LinuxThreads) real-time
signals (see pthreads(7)), and adjusts the value of SIGRTMIN suitably
(to 34 or 35).  

Because the range of available real-time signals varies according to the glibc threading implementation (and this
variation can occur at run time according to the available kernel and
glibc), and indeed the range of real-time signals varies across UNIX
systems, programs should never refer to real-time signals using hard-
coded numbers, but instead should always refer to real-time signals
using the notation SIGRTMIN+n, and include suitable (run-time) checks
that SIGRTMIN+n does not exceed SIGRTMAX.
...

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s