The Linux Programming Interface

454 Chapter 22

Order of delivery of multiple unblocked signals

If a process has multiple pending signals that are unblocked using sigprocmask(),

then all of these signals are immediately delivered to the process.

As currently implemented, the Linux kernel delivers the signals in ascending

order. For example, if pending SIGINT (signal 2) and SIGQUIT (signal 3) signals were

both simultaneously unblocked, then the SIGINT signal would be delivered before

SIGQUIT, regardless of the order in which the two signals were generated.

We can’t, however, rely on (standard) signals being delivered in any particular

order, since SUSv3 says that the delivery order of multiple signals is implementation-

defined. (This statement applies only to standard signals. As we’ll see in Section 22.8,

the standards governing realtime signals do provide guarantees about the order in

which multiple unblocked realtime signals are delivered.)

When multiple unblocked signals are awaiting delivery, if a switch between

kernel mode and user mode occurs during the execution of a signal handler, then

the execution of that handler will be interrupted by the invocation of a second signal

handler (and so on), as shown in Figure 22-1.

Figure 22-1: Delivery of multiple unblocked signals

22.7 Implementation and Portability of signal().....................................................................

In this section, we show how to implement signal() using sigaction(). The implemen-

tation is straightforward, but needs to account for the fact that, historically and

across different UNIX implementations, signal() has had different semantics. In

particular, early implementations of signals were unreliable, meaning that:

z On entry to a signal handler, the disposition of the signal was reset to its

default. (This corresponds to the SA_RESETHAND flag described in Section 20.13.)

In order to have the signal handler invoked again for a subsequent delivery of

the same signal, the programmer needed to make a call to signal() from within the

handler to explicitly reestablish the handler. The problem in this scenario is

that there is a small window of time between entering the signal handler and

reestablishment of the handler, during which, if the signal arrives a second

time, it would be processed according to its default disposition.

Main program

return

SIGINT

handler

24

3

flow of execution

1

return

SIGQUIT

handler

1. Pending SIGINT and SIGQUIT unblocked


2. Kernel invokes handler for SIGINT


3. SIGINT handler makes a system call


4. Kernel invokes handler for SIGQUIT