The Linux Signals Handling Model

Communication is the key to healthy relationships between threads and the kernel; these are the signals they use to communicate.

Signals are used to notify a process or thread of a particular event. Many computer science researchers compare signals with hardware interrupts, which occur when a hardware subsystem, such as a disk I/O (input/output) interface, generates an interrupt to a processor when the I/O completes. This event in turn causes the processor to enter an interrupt handler, so subsequent processing can be done in the operating system based on the source and cause of the interrupt.

UNIX guru W. Richard Stevens aptly describes signals as software interrupts. When a signal is sent to a process or thread, a signal handler may be entered (depending on the current disposition of the signal), which is similar to the system entering an interrupt handler as the result of receiving an interrupt.

Operating system signals actually have quite a history of design changes in the signal code and various implementations of UNIX. This was due in part to some deficiencies in the early implementation of signals, as well as the parallel development work done on different versions of UNIX, primarily BSD UNIX and AT&T System V. James Cox, Berny Goodheart and W. Richard Stevens cover these details in their respective well-known books, so they don't need to be repeated here.

Implementation of correct and reliable signals has been in place for many years now, where an installed signal handler remains persistent and is not reset by the kernel. The POSIX standards provided a fairly well-defined set of interfaces for using signals in code, and today the Linux implementation of signals is fully POSIX-compliant. Note that reliable signals require the use of the newer sigaction interface, as opposed to the traditional signal call.

The occurrence of a signal may be synchronous or asynchronous to the process or thread, depending on the source of the signal and the underlying reason or cause. Synchronous signals occur as a direct result of the executing instruction stream, where an unrecoverable error (such as an illegal instruction or illegal address reference) requires an immediate termination of the process. Such signals are directed to the thread which caused the error with its execution stream. As an error of this type causes a trap into a kernel trap handler, synchronous signals are sometimes referred to as traps.

Asynchronous signals are external to (and in some cases, unrelated to) the current execution context. One obvious example would be the sending of a signal to a process from another process or thread via a kill(2), _lwp_kill(2) or sigsend(2) system call, or a thr_kill(3T), pthread_kill(3T) or sigqueue(3R) library invocation. Asynchronous signals are also aptly referred to as interrupts.

Every signal has a unique signal name, an abbreviation that begins with SIG (SIGINT for interrupt signal, for example) and a corresponding signal number. Additionally, for all possible signals, the system defines a default disposition or action to take when a signal occurs. There are four possible default dispositions:

  • Exit: forces the process to exit.

  • Core: forces the process to exit and create a core file.

  • Stop: stops the process.

  • Ignore: ignores the signal; no action taken.

A signal's disposition within a process's context defines what action the system will take on behalf of the process when a signal is delivered. All threads and LWPs (lightweight processes) within a process share the signal disposition, which is processwide and cannot be unique among threads within the same process.

Table 1

Table 1 provides a complete list of signals, along with a description and default action. The data structures in the kernel to support signals in Linux are to be found in the task structure. Here are the most common elements of said structure pertaining to signals:

  • current-->sig are the signal handlers.

  • sigmask_lock is a per-thread spinlock which protects the signal queue and atomicity of other signal operations.

  • current-signal and current-blocked contain a bitmask (currently 64 bits long, but freely expandable) of pending and permanently blocked signals.

  • sigqueue and sigqueue_tail is a double-linked list of pending signals—Linux has RT signals which can be queued as well. “Traditional” signals are internally mapped to RT signals.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

I have One Question about the

Zafar's picture

I have One Question about the Usage of SIGNAL() and SIGACTION() so which function shall I Use. Is the use of traditional SIGNAL() is a disadvantage.

"Asynchronous signals are

Ling's picture

"Asynchronous signals are delivered to the first thread found not blocking the signal." The only solution I found so far is to create a thread to process all signals, and mask the rest of the threads.

This makes the signal pretty useless on Android, as we don't have control of how threads are created, and the system might use other signals.

I have read some suggestion and working solution in the kernel to deliver the signal to the originated thread, instead of random thread.

I wonder if the latest kernel is supporting this, or if anyone has solution for this.

Thanks!

Signal Handling

Anonymous's picture

Is there a pictorial representation of the signal handling process in Linux to help visualize the switch between the user space and kernel space?

What does 'reliable' mean? What happens if a signal is unreliabl

Ming's picture

"Implementation of correct and reliable signals has been in place for many years now ... reliable signals require the use of the newer sigaction interface" - What is the definition of 'reliable signals'? Are there some signals reliable and some not, in the same implementation? Or are there reliable implementations in which all signals are reliable, and unreliable implementations where all signals are unreliable?
And I have a question that is not answered in all the papers and books I have read so far: what happens if a signal arrives when a previous one (of the same type) is being handled in a signal catching function?

RE: What does 'reliable' mean?

Anonymous's picture

I trust reliable is referred to in the sense that some functions makes the entire signaling handling reliable, e.g. 'sigaction' may block signals and set a new signal handler in one atomic swoop, as to eliminate the potential race condition.
As to your last question, if the signal is not blocked and a new instance is generated in the midst of the processing of the last one, then the signal handler must be re-entrant. IMHO, the best method is to block the signal on entering the signal handler. It will be automatically restored on exit. On old UNIX versions, once a signal handler is invoked, the signal handling is reverted to default. If a new signal instance comes along, it will be treated the default way, most often terminating the process.

Table 1 HTML lacks tag

Anonymous's picture

Table 1 HTMl page lacks start tag for the table, making the page unrenderable, even if the article is dated in year 2000.

start tag.

Keith Daniels's picture

Thanks for catching that. I will fix it ASAP

Webmaster - Linux Journal

All the new OSs and windowing systems are oriented towards content consumption instead of content production.

--Steve Daniels 2013

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix