Real-time Signals
Linux supports real-time signals as originally defined in the POSIX.4 real-time extensions (and now included in POSIX 1003.1-2001). Linux supports
32 real-time signals, numbered from 32 (SIGRTMIN) to 63 (SIGRTMAX). (Programs should always refer to real-time signals using notation SIGRTMIN+n,
since the range of real-time signal numbers varies across Unices.)
Unlike standard signals, real-time signals have no predefined meanings: the entire set of real-time signals can be used for application-defined
purposes. (Note, however, that the LinuxThreads implementation uses the first three real-time signals.)
The default action for an unhandled real-time signal is to terminate the receiving process.
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(2), 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.)
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.
According to POSIX, an implementation should permit at least _POSIX_SIGQUEUE_MAX (32) real-time signals to be queued to a process. However, Linux
does things differently. In kernels up to and including 2.6.7, Linux imposes a system-wide limit on the number of queued real-time signals for all
processes. This limit can be viewed and (with privilege) changed via the /proc/sys/kernel/rtsig-max file. A related file, /proc/sys/kernel/rtsig-
nr, can be used to find out how many real-time signals are currently queued. In Linux 2.6.8, these /proc interfaces were replaced by the
RLIMIT_SIGPENDING resource limit, which specifies a per-user limit for queued signals; see setrlimit(2) for further details.
[^] # Re: Real time event ?
Posté par rdg . En réponse au journal Noyau: code relatif à l'HyperThreading défectueux?. Évalué à 1.
Real-time Signals
Linux supports real-time signals as originally defined in the POSIX.4 real-time extensions (and now included in POSIX 1003.1-2001). Linux supports
32 real-time signals, numbered from 32 (SIGRTMIN) to 63 (SIGRTMAX). (Programs should always refer to real-time signals using notation SIGRTMIN+n,
since the range of real-time signal numbers varies across Unices.)
Unlike standard signals, real-time signals have no predefined meanings: the entire set of real-time signals can be used for application-defined
purposes. (Note, however, that the LinuxThreads implementation uses the first three real-time signals.)
The default action for an unhandled real-time signal is to terminate the receiving process.
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(2), 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.)
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.
According to POSIX, an implementation should permit at least _POSIX_SIGQUEUE_MAX (32) real-time signals to be queued to a process. However, Linux
does things differently. In kernels up to and including 2.6.7, Linux imposes a system-wide limit on the number of queued real-time signals for all
processes. This limit can be viewed and (with privilege) changed via the /proc/sys/kernel/rtsig-max file. A related file, /proc/sys/kernel/rtsig-
nr, can be used to find out how many real-time signals are currently queued. In Linux 2.6.8, these /proc interfaces were replaced by the
RLIMIT_SIGPENDING resource limit, which specifies a per-user limit for queued signals; see setrlimit(2) for further details.