IPC (pipes & signals)
How two processes share bytes (pipes) and how they interrupt each other (signals)
In a nutshell
Once you have two processes, they usually need to talk. A pipe is a unidirectional byte stream the kernel maintains between two file descriptors. The shell’s | is a pipe. Signals are asynchronous notifications: SIGINT when you press Ctrl-C, SIGCHLD when a child process exits, SIGTERM when someone politely asks you to quit. You install a signal handler to react to them.
Why it matters
Pipes are how every Unix pipeline works. Signals are how the shell job-control model works (Ctrl-C, Ctrl-Z) and how long-running daemons are told to reload config (SIGHUP). Both land directly in CSCD 340 (Operating Systems) and CSCD 330 (Networks).
Key takeaways
pipe(int fds[2])creates a pipe.fds[0]is the read end,fds[1]is the write end. Typicallyforkand have the child use one end, the parent the other.dup2(src, dst)redirects a file descriptor.dup2(pipe_fd, STDIN_FILENO)is how a program reads from a pipe as if it were stdin.- Pipes are byte streams, not message queues. Short reads are possible; you loop until you have what you need.
signal(sig, handler)/sigaction(...)install a signal handler.signalis older and has portability quirks;sigactionis the safe modern API.- Signal handlers run in a restricted context. Use async-signal-safe functions only. The common pattern is “set a
volatile sig_atomic_tflag in the handler; check it in the main loop.”
Lessons in this topic
| Lesson | What it covers |
|---|---|
| Pipes & Signals | Creating pipes, wiring them to stdin/stdout, installing signal handlers, the async-signal-safe rule |
Practice and deep dives
Practice this topic: Pipes & Signals drill, or browse the practice gallery.
What comes next
Synthesis — tying everything in the course together in a final lab.