Operational semantics for signal handling

Signals are a lightweight form of interprocess communication in Unix. When a process receives a signal, the control flow is interrupted and a previously installed signal handler is run. Signal handling is reminiscent both of exception handling and concurrent interleaving of processes. In this paper, we investigate different approaches to formalizing signal handling in operational semantics, and compare them in a series of examples. We find the big-step style of operational semantics to be well suited to modelling signal handling. We integrate exception handling with our big-step semantics of signal handling, by adopting the exception convention as defined in the Definition of Standard ML. The semantics needs to capture the complex interactions between signal handling and exception handling.

💡 Research Summary

The paper presents a formal operational semantics for Unix‑style signal handling, emphasizing the interplay between signals, exceptions, and concurrency. Signals are lightweight asynchronous notifications that interrupt a process’s control flow and invoke a previously installed handler. While this mechanism resembles exception handling—both involve non‑local transfer of control—it also exhibits concurrency‑like interleaving because handlers can be invoked at arbitrary points during execution, and multiple signals may be pending simultaneously. Existing small‑step semantics capture the step‑by‑step state transitions of such systems, but they become unwieldy when modeling dynamic installation and removal of handlers, nested signal deliveries, and the interaction with exception propagation.

To address these challenges, the authors adopt a big‑step (natural) semantics framework. In this approach, the evaluation relation ⟨c, σ⟩ ⇓ ⟨σ′, r⟩ maps a command c and an initial state σ to a final state σ′ and a result r (either a value or an exception). Signal handlers are stored as metadata attached to the state, forming a stack‑like mapping from signal identifiers to handler commands. When a signal is delivered, the semantics looks up the most recent handler, inserts its command into the evaluation, and proceeds with a new big‑step evaluation of that handler. After the handler finishes, the resulting state is merged back into the original computation, which then resumes as if the interruption had never occurred, except for the side‑effects produced by the handler.

Exception handling is integrated by following the convention used in the Definition of Standard ML. An evaluation that raises an exception e is denoted ⟨c, σ⟩ ⇓ ⟨σ′, raise e⟩. If a handler itself raises an exception, the usual exception propagation rules apply, allowing the exception to escape the handler and be caught by an outer try‑catch construct. Crucially, the semantics permits signals to be delivered while a handler is already executing; the state’s handler mapping can be updated dynamically, enabling true nesting of signal deliveries. The authors also define a deterministic priority rule: exceptions take precedence over pending signals when both are ready to be processed, thereby eliminating ambiguity.

The paper validates the proposed semantics through a series of illustrative examples. The first example demonstrates basic installation, delivery, and removal of a single signal. The second example shows nested signal delivery: a handler installs a new handler and a second signal arrives before the first handler returns. The third example explores a handler that raises an exception, illustrating how the exception propagates outward and can be caught by surrounding code. The fourth example combines both phenomena, where an exception is being handled when another signal arrives, confirming that the priority rule correctly determines the order of processing. In each case, the big‑step semantics yields concise, compositional rules that match the intuitive behavior of Unix signal handling, whereas a comparable small‑step model would require intricate bookkeeping of intermediate states.

Beyond modeling, the authors discuss the practical benefits of a big‑step approach for static analysis and verification. Because the semantics directly relates whole program fragments to their final outcomes, it integrates naturally with abstract interpretation frameworks and model‑checking tools that operate on whole‑program abstractions. The handler metadata can be treated as an abstract domain, allowing analyses to reason about possible pending signals without enumerating every interleaving. This opens the door to automated verification of properties such as “no signal handler leaves the program in an inconsistent state” or “exceptions raised inside handlers are always caught.”

In conclusion, the paper argues that big‑step operational semantics provides a clean, expressive, and analytically tractable foundation for reasoning about signal handling, especially when combined with exception handling. It captures the essential control‑flow disruptions, dynamic handler management, and priority interactions without the overhead of low‑level stepwise transitions. The authors suggest future work on extending the semantics to multi‑threaded environments, incorporating real‑time constraints, and building tool support that automatically extracts the formal model from existing code bases.