Courses/Computer Science/CPSC 457.F2014/Lecture Notes/SignalsIPC
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: signals.pdf
Some C notes on shared memory: http://www.cs.cf.ac.uk/Dave/C/node27.html
signal handler data structures in task_struct: http://lxr.linux.no/#linux+v22.214.171.124/include/linux/sched.h#L1327
definition of sighand_struct: http://lxr.linux.no/#linux+v126.96.36.199/include/linux/sched.h#L441
definition of signal_struct: http://lxr.linux.no/#linux+v188.8.131.52/include/linux/sched.h#L523
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.