3/16/16 CSE 506: Opera.ng Systems CSE 506: Opera.ng Systems Housekeeping Signals and Inter-Process • Paper reading assigned for next class Communica.on Don Porter 1 2 CSE 506: Opera.ng Systems CSE 506: Opera.ng Systems Logical Diagram Last Nme… Binary Memory • We’ve discussed how the OS schedules the CPU Threads Formats Allocators – And how to block a process on a resource (disk, network) User Today’s Lecture System Calls Kernel Process • Today: CoordinaNon – How do processes block on each other? RCU File System Networking Sync – And more generally communicate? Memory Device CPU Management Scheduler Drivers Hardware Disk Net Consistency Interrupts 3 4 CSE 506: Opera.ng Systems CSE 506: Opera.ng Systems Outline What is a signal? • Signals • Like an interrupt, but for applicaNons – Overview and APIs – < 64 numbers with specific meanings – Handlers – A process can raise a signal to another process or thread – Kernel-level delivery – A process or thread registers a handler funcNon – Interrupted system calls • For both IPC and delivery of hardware excepNons • Interprocess CommunicaNon (IPC) – ApplicaNon-level handlers: divzero, segfaults, etc. – Pipes and FIFOs • No “message” beyond the signal was raised – System V IPC – And maybe a lible metadata – Windows Analogs • PID of sender, faulNng address, etc. • But placorm-specific (non-portable) 5 6 1
3/16/16 CSE 506: Opera.ng Systems CSE 506: Opera.ng Systems Example Example Pid 300 Pid 300 Pid 400 int main() { int main() { ... ... PC kill(300, SIGUSR1); signal(SIGUSR1, &usr_handler); } ... } int usr_handler() { … Register usr_handler() to handle SIGUSR1 Send signal to PID 300 7 8 CSE 506: Opera.ng Systems CSE 506: Opera.ng Systems Basic Model Signal Types • See man 7 signal for the full list: (varies by sys/arch) • ApplicaNon registers handlers with signal or sigacNon SIGTSTP – 1 – Stop typed at terminal (Ctrl+Z) • Send signals with kill and friends SIGKILL – 9 – Kill a process, for realzies – Or raised by hardware excepNon handlers in kernel SIGSEGV – 11 – SegmentaNon fault • Signal delivery jumps to signal handler SIGPIPE – 13 – Broken pipe (write with no readers) – Irregular control flow, similar to an interrupt SIGALRM – 14 – Timer SIGUSR1 – 10 – User-defined signal 1 SIGCHLD – 17 – Child stopped or terminated SIGSTOP – 19 – Stop a process SIGCONT – 18 – ConNnue if stopped API names are admibedly confusing 9 10 CSE 506: Opera.ng Systems CSE 506: Opera.ng Systems Language ExcepNons Signal Handler Control Flow • Signals are the underlying mechanism for ExcepNons User Mode Kernel Mode and catch blocks Normal program do_signal() • JVM or other runNme system sets signal handlers flow handle_signal() – Signal handler causes execuNon to jump to the catch block setup_frame() Signal handler Return code system_call() on the stack sys_sigreturn() restore_sigcontext() Figure 11-2. Catching a signal From Understanding the Linux Kernel 11 12 2
3/16/16 CSE 506: Opera.ng Systems CSE 506: Opera.ng Systems Alternate Stacks Nested Signals • Signal handlers execute on a different stack than • What happens when you get a signal in the signal program execuNon. handler? – Why? • And why should you care? • Safety: App can ensure stack is actually mapped – And avoid assumpNons about applicaNon not using space below rsp – Set with sigaltstack() system call • Like an interrupt handler, kernel pushes register state on interrupt stack – Return to kernel with sigreturn() system call – App can change its own on-stack register state! 13 14 CSE 506: Opera.ng Systems CSE 506: Opera.ng Systems The Problem with NesNng Nested Signals int main() { • The original signal() specificaNon was a total mess! /* ... */ – Now deprecated---do not use! Another signal signal(SIGINT, &handler); • New sigacNon() API lets you specify this in detail delivered on Double free! signal(SIGTERM, &handler); – What signals are blocked (and delivered on sigreturn) return /* ... */ – Similar to disabling hardware interrupts PC Calls } munmap() • As you might guess, blocking system calls inside of a Signal Stack signal handler are only safe with careful use of int handler() { SIGINT sigacNon() free(buf1); SIGTERM free(buf2); } 15 16 CSE 506: Opera.ng Systems CSE 506: Opera.ng Systems ApplicaNon vs. Kernel Example • App: signals appear to be delivered roughly Mark pending immediately … signal, Pid 300 10 Pid 300 Pid 400 • Kernel (lazy): … Block on disk unblock RUNNING INTERRUPTIBLE read! – Send a signal == mark a pending signal in the task • And make runnable if blocked with TASK_INTERRUPTIBLE flag – Check pending signals on return from interrupt or syscall int main() { What happens • Deliver if pending read(); to read? PC kill(300, SIGUSR1); } int usr_handler() { … Send signal to PID 300 17 18 3
3/16/16 CSE 506: Opera.ng Systems CSE 506: Opera.ng Systems Interrupted System Calls Default handlers • If a system call blocks in the INTERRUPTIBLE state, a • Signals have default handlers: signal wakes it up – Ignore, kill, suspend, conNnue, dump core – These execute inside the kernel • Yet signals are delivered on return from a system call • Installing a handler with signal/sigacNon overrides • How is this resolved? the default • The system call fails with a special error code • A few (SIGKILL) cannot be overridden – EINTR and friends – Many system calls transparently retry aver sigreturn – Some do not – check for EINTR in your applicaNons! 19 20 CSE 506: Opera.ng Systems CSE 506: Opera.ng Systems RT Signals Signal Summary • Default signals are only in 2 states: signaled or not • AbstracNon like hardware interrupts – If I send 2 SIGUSR1’s to a process, only one may be – Some care must be taken to block other interrupts delivered – Easy to write buggy handlers and miss EINTR – If system is slow and I furiously hit Ctrl+C over and over, • Understand control flow from applicaNon and kernel only one SIGINT delivered perspecNve • Real Nme (RT) signals keep a count • Understand basic APIs – Deliver one signal for each one sent 21 22 CSE 506: Opera.ng Systems CSE 506: Opera.ng Systems Other IPC Pipes • Pipes, Sockets, and FIFOs • Stream of bytes between two processes • System V IPC • Read and write like a file handle • Windows comparison – But not anywhere in the hierarchical file system – And not persistent – And no cursor or seek()-ing – Actually, 2 handles: a read handle and a write handle • Primarily used for parent/child communicaNon – Parent creates a pipe, child inherits it 23 24 4
3/16/16 CSE 506: Opera.ng Systems CSE 506: Opera.ng Systems Example FIFOs (aka Named Pipes) int pipe_fd[2]; • ExisNng pipes can’t be opened---only inherited int rv = pipe(pipe_fd); – Or passed over a Unix Domain Socket (beyond today’s lec) int pid = fork(); if (pid == 0) { • FIFOs, or Named Pipes, add an interface for opening close(pipe_fd[1]); //Close unused write end exisNng pipes dup2(pipe_fd[0], 0); // Make the read end stdin exec(“grep”, “quack”); } else { close (pipe_fd[0]); // Close unused read end … 25 26 CSE 506: Opera.ng Systems CSE 506: Opera.ng Systems Sockets Select • Similar to pipes, except for network connecNons • What if I want to block unNl one of several handles has data ready to read? • Setup and connecNon management is a bit trickier • Read will block on one handle, but perhaps miss data – A topic for another day (or class) on a second… • Select will block a process unNl a handle has data available – Useful for applicaNons that use pipes, sockets, etc. 27 28 CSE 506: Opera.ng Systems CSE 506: Opera.ng Systems Synthesis Example: The Shell Shell Example • Almost all ‘commands’ are really binaries • Ex: ls | grep foo – /bin/ls • ImplementaNon sketch: • Key abstracNon: RedirecNon over pipes – Shell parses the enNre string – ‘>’, ‘<‘, and ‘|’implemented by the shell itself – Sets up chain of pipes – Forks and exec’s ‘ls’ and ‘grep’ separately – Wait on output from ‘grep’, print to console 29 30 5
Recommend
More recommend