Courses/Computer Science/CPSC 457.W2012/Lecture Notes/Signals

Jump to: navigation, search

Simple IPC: Signals

Running programs and software applications are not terribly useful if they run in isolation; they often need data that other processes have, control, or generate. Composing processing and communications pipelines is one of the ways we create interesting emergent behavior out of very simple components.

Operating systems include support for allowing processes to (carefully!) break through the isolation typically imposed on each process.


  • Signals - signals provide one of the most fundamental ways the OS, hardware (via the OS), and other processes can communicate with each other. We've seen a few signals in action, but we will consider the signaling mechanism itself from the OS view. The question is: how does the OS represent and deliver signals?
  • Shared memory - shared memory represents one of conceptually easiest ways to understand coordinated access to the "same" memory or data
  • System V IPC - more general IPC mechanism require support for namespaces, various forms of locking, and message passing. Such design patterns and artifacts closely mimic microkernel based OS designs (but at a different level of abstraction).


Slides from today:

Some C notes on shared memory:

signal handler data structures in task_struct:

definition of sighand_struct:

definition of signal_struct:

the send_signal() function which invokes __send_signal()

the handle_signal() function.

Case Study: ptrace(2) We will focus on the ptrace(2) mechanism; this is a prime example of the OS allowing a process to break through the normal "protection" and isolation to supervise another process; most of this control is accomplished via signal delivery.

The ptrace(2) entry point

Code to download and modify:


None, work on HW3 and HW4

Supplemental readings can be found in ULK: Chapter 11, "Signals"