Why linux decides that standard signals have highe

Question

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.

Literally,real-time signals have this name because it needs to be processed ASAP,almost real-time.

But why linux gives it a less higher priority than standard signals?

Answer 1

Maybe because real time signals are queued, so giving them lower priority makes it less likely that you will "miss" a signal.

Answer 2

It may have to do with the fact that realtime signals are queued whereas regular signals are not. That means if two realtime signals are activated in quick succession (before it can be actioned), your signal handler will be called twice.

If that happens with a regular signal, one will be 'lost' (though this is easy enough to engineer around).

I think the intent is to keep the two types of signal distinct. An application built for POSIX.4 will most likely use the realtime interrupts for as much as possible, leaving regular interrupts for rare things like exit conditions.

In other words, you would no longer use USR1 for configuration reloads (as some programs do) but would choose one of the lower priority realtime interrupts for this.

The use of realtime signals gives you what you need for a proper realtime application:

• no lost events.
• priority order so application can ensure important things happen in preference to less important ones - I believe this is the realtime aspect, similar to ensuring higher priority threads always run in preference to lower ones.
• multiplexing of signals (sending additional data with a signal).

---

Part of the rationale behind realtime signals can be found in a whitepaper authored by Michael González Harbour et al, entitled "REAL-TIME POSIX: AN OVERVIEW". An extraction is below:

The signal mechanism defined in POSIX.1 allows to notify events occurring in the system, but is not completely satisfactory for real-time applications. The signals are not queued, and thus some events may be lost. Signals are not prioritized, and this implies longer response times for urgent events. Also, events of the same kind produce signals with the same number, which are indistinguishable. Since many real-time systems are heavily based on the rapid exchange of events in the system, POSIX.4 has extended the signals interface to achieve the following features:

• Real-time signals are queued, so events are not lost
• Pending real-time signals are dequeued in priority order, using the signal number as the priority. This allows designing applications with faster response times to urgent events.
• Real-time signals contain an additional data field that may be used by the application to exchange data between the signal generator and the signal handler. For example, this data field may be used to identify the source of the signal.
• The range of signals available to the application is expanded.