Geek Answers Handbook

Why does linux decide that standard signals take precedence over rt signals?

If both standard and real-time signals are waiting for the process, POSIX leaves it unspecified that the first has been delivered. Linux, like many other implementations, in this case, priority is given to standard signals.

Literally, real-time signals have this name, because they need to be processed as soon as possible, in real time.

But why does linux give it a lower priority than standard signals?

+4
source share
2 answers

Perhaps because real-time signals are queued, so at a lower priority this reduces the likelihood that you will “miss” the signal.

+2
source

Perhaps this is due to the fact that the signals in real time are queued, while there are no regular signals. This means that if two fast signals are activated quickly (before they can be activated), your handler will be called twice.

If this happens with a normal signal, one will be "lost" (although this is easy enough to develop).

I think the intention is to keep the two types of signal different. An application built for POSIX.4 will most likely use real-time interrupts to the maximum extent possible, leaving regular interrupts for rare things like exit conditions.

In other words, you will no longer use USR1 to reload the configuration (as some programs do), but would choose one of the low-priority real-time interrupts for this.

Using real-time signals gives you what you need for a proper real-time application:

  • no lost events.
  • priority, so the application can ensure that important things happen in preference less important - I think this is a real-time aspect, similar to the fact that higher priority threads always work in lower preference.
  • signal multiplexing (sending additional data using a signal).

Part of the rationale for real-time signals can be found in a white paper authored by Michael Gonzalez Harbor et al. Entitled "POSIX REAL TIME: REVIEW." Extraction below:

The signal mechanism defined in POSIX.1 allows you to notify events occurring in the system, but is not entirely satisfactory for real-time applications. Signals are not queued, and therefore some events may be lost. Signals have no priority, and this implies a longer response time for urgent events. In addition, events of the same type produce signals with the same number, which are indistinguishable. Since many real-time systems are largely based on the rapid exchange of events in the system, POSIX.4 has expanded the signal interface to achieve the following features:

  • Real-time signals are queued, so events are not lost.
  • Real-time pending signals are preempted using the signal number as priority. This allows you to develop applications with faster response times to urgent events.
  • Real-time signals contain an additional data field that the application can use to exchange data between the signal generator and the signal processor. For example, this data field may be used to identify a signal source.
  • The range of signals available for the application is expanding.
+1
source

More articles:


All Articles