Signals act as asynchronous notifications informing processes of specific events. Before an operating system executes a signal handler, it must verify that the timing is appropriate for safe execution. Generally, signal actions are triggered only when transitioning from kernel space back to user space.

Standard vs. Blocked Scenarios

In standard flows, if a signal arrives while not masked, the kernel records its pending status but does not interrupt the current instruction stream immediately. Processing waits for the next scheduled opportunity. Conversely, if a signal is explicitly blocked, it remains in a pending state until the mask is cleared. Once unblocked, delivery becomes immediate upon the next suitable transition point.

Signal generation is asynchronous relative to process logic. A process might be engaged in critical operations, such as extensive I/O handling, when a termination request occurs. Halting these tasks abruptly could corrupt data or degrade performance. Therefore, the system defers action until the process completes high-priority work within kernel context before returning control to user space.

Upon this return, the scheduler detects pending signals and invokes the configured response: default termination, explicit ignoring, or custom callback execution.

Execution Modes and Memory Isolation

Understanding signal mechanics requires distinguishing between execution modes:

• User Mode: Runs application-specific code auhtored by developers.
• Kernel Mode: Executes privileged OS routines including schedulers, device drivers, and interrupt handlers.

Transitions occur frequently during system operation:

1. User to Kernel: Triggered by system calls (e.g., read, write), hardware interrupts, or exceptions.
2. Kernel to User: Occurs after system call completion, context switches, or interrupt servicing.

Signal processing specifically relies on the Kernel to User transition. Only during this handover does the system check for valid signal delivery.

Address Space and Control Registers

Processes utilize a virtual address space managed by page tables and the Memory Management Unit (MMU). While each process maintains its own virtual space, the upper portion (typically 1 GB on 32-bit x86 architectures) represents shared kernel space containing OS code and data. This region uses specialized kernel-level page tables mapped physically to RAM.

Hardware distinguishes modes using CPU Control Registers. Specifically, the CR3 register tracks privilege rings. A value indicating Ring 3 corresponds to user applications, whereas Ring 0 denotes kernel operations. Switching modes involves updating these registers to alter access privileges, preventing user code from tampering with sensitive OS regions.

Process scheduling relies on timer interrupts. When a time slice expires, hardware generates an interrupt, invoking the kernel scheduler (schedule()) to save the current context and select the next runnable task.

Signal Handler Execution Mechanics

When a signal indicates a user-defined handler is registered, the delivery mechanism becomes more complex due to stack separation. The handler runs in user space, but the main program also runs there. They cannot simply return to each other's stacks safely.

The sequence involves:

1. Kernel Detection: Upon returning to user space, the kernel identifies pending unmasked signals.
2. Context Save: The kernel saves sufficient state to resume the interrupted thread later.
3. Stack Switch: The CPU switches to the signal delivery stack.
4. User Handler: The registered function executes.
5. Sigreturn: After the handler finishes, a sigreturn system call is required to restore the original context and re-enter kernel mode briefly before finally resuming the main flow.

Running the handler in user mode limits potential damage. If executed in kernel mode, buggy signal handlers could crash the entire system. User-mode isolation ensures recovery paths remain stable even if the handler fails.

Configuring Signal Actions via sigaction

While older interfaces exist, sigaction provides robust control over how signals behave. It allows masking specific signals during handler execution and defining precise behaviors.

#include <signal.h>
#include <stdio.h>
#include <unistd.h>

void handle_interrupt(int signum) {
    printf("Received signal %d\n", signum);
}

int main(void) {
    struct sigaction sa;
    
    // Initialize the action structure
    sa.sa_handler = handle_interrupt;
    sa.sa_flags = 0;
    sigemptyset(&sa.sa_mask); // Initially block no signals
    
    // Register the handler for SIGINT
    if (sigaction(SIGINT, &sa, NULL) == -1) {
        perror("Failed to set signal handler");
        return 1;
    }
    
    // Keep process running
    while(1) {
        pause();
    }
    return 0;
}

The sigaction structure includes fields like sa_mask to define which signals should be temporarily blocked while the handler runs. This prevents recursive interruptions or race conditions. Validating the return value ensures configuration success; -1 indicates failure with errno updated accordingly.

Lifecycle Summary

Signals follow a defined lifecycle from creation to final consumption. Generation sources include keyboard inputs, inter-process communication, software faults, or hardware traps. Upon creation, signals enter kernel tracking structures, remaining pending until processed or blocked. Execution is restricted to transitions from kernel context back to user space. Default policies typically terminate threads, null actions discard notifications silently, and registered callbacks enable custom recovery logic. Understanding these mechanics ensures stable application architecture.