• core dump files
• special cases regarding signal delivery, disposition, handling
• synchronous and asynchronous generation of signals
• when and in what order signals are delivered
• interruption of syscalls by signal handlers, and how to automatically restart interrupted syscalls
• realtime signals
• the use of sigsuspend() to set the process signal mask and wait for a signal to arrive
• the use of sigwaitinfo() (and sigtimedwait()) to asynchronously wait for a signal to arrive
• the use of signalfd() to receive a signal via file descriptor

Core dump files

Special cases for delivery, disposition and handling

Interruptible and uninterruptible process sleep

Hardware-Generated Signals

Synchronous and Asynchronous Signal Generating

Timing and order of signal delivery

Implementation and Portability of signal

Realtime Signals

Waiting for a signal using a mask sigsuspend

Synchronously Waiting for a signal

Fetching signals via a file descriptor

Interprocess Communication with Signals

Summary

Certain signals cause a process to create a core dump and terminate. This file contains information that can be used by a debugger to inspect the state of a process at the time that is terminated. By default, a core dump file is named core, but Linux provides the /proc/sys/kernel/core_pattern file to control the naming of core dump files.

A signal may be generated asynchronously or synchronously. Asynchronous generation occurs when a signal is sent to a process by the kernel or by another process. A process can’t predict precisely when an asychronously generated signal will be delivered. (We noted that asynchronous signals are normally delivered the next time the receiving process switches from kernel mode to user mode.) Synchronous generation occurs when the process itself executes code that directly generates the signal-for example, by executing an instruction that causes a hardware exception or by calling raise(). The delivery of a synchronously generated signal is precisely predictable.

Realtime signals are a POSIX addition to the original signal model, and differ from standard signals in that they are queued, have a specified delivery order, and can be sent with an accompanying piece of data. Realtime signals are designed to be used for application-defined purpose. A realtime signal is sent using the sigqueue() syscall, and an additional argument (the siginfo_t structure) is supplied to the signal handler so that it can obtain the data accompanying the signal, as well as the process ID and real user ID of the sending proces.

The sigsuspend syscall allows a program to atomically modify the process signal mask and suspend execution until a signal arrives. The atomicity of sigsuspend() is essential to avoid race conditions when unblocking a signal and then suspending execution until that signal arrives.

We can use sigwaitinfo and sigtimedwait to synchronously wait for a signal. This saves us the work of designing and writing a signal handler, which may be unnecessary if our only aim is to wait for the delivery of a signal.

The signalfd syscall can be used to synchronously wait for a signal. The distinctive feature of this interface is that signals can be read via a file descriptor. This file descriptor can also be monitored using select, poll, and epoll.