Will become zombies when they terminate will never be

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: another command   Some programs run “for a long &me”   Example: “delete this file in two hours” unix> sleep 7200; rm /tmp/junk   # shell stuck for 2 hours A “background” job is a process we don't want to wait for unix> (sleep 7200 ; rm /tmp/junk) & [1] 907 unix> # ready for next command 9 Carnegie Mellon Problem with Simple Shell Example     Our example shell correctly waits for and reaps foreground jobs But what about background jobs?         Will become zombies when they terminate Will never be reaped because shell (typically) will not terminate Will create a memory leak that could run the kernel out of memory Modern Unix: once you exceed your process quota, your shell can't run any new commands for you: fork() returns  ­1 unix> limit maxproc maxproc 202752 unix> ulimit -u 202752 # csh syntax # bash syntax 10 Carnegie Mellon ECF to the Rescue!   Problem   The shell doesn't know when a background job will finish   By nature, it could happen at any 2me   The shell's regular control flow can't reap exited background processes in a 2mely fashion   Regular control flow is “wait un2l running job completes, then reap it”   Solu&on: Excep&onal control flow   The kernel will interrupt regular processing to alert us when a background process completes   In Unix, the alert mechanism is called a signal 11 Carnegie Mellon Today       Mul&tasking, shells Signals Nonlocal jumps 12 Carnegie Mellon Signals   A signal is a small message that no&fies a process that an event of some type has occurred in the system   akin to excep2ons and interrupts   sent from the kernel (some2mes at the request of another process) to a process   signal type is iden2fied by small integer ID’s (1 ­30)   only informa2on in a signal is its ID and the fact that it arrived ID Name Default Ac)on Corresponding Event 2 SIGINT Terminate Interrupt (e.g., ctl ­c from keyboard) 9 SIGKILL Terminate Kill program (cannot override or ignore) 11 SIGSEGV Terminate & Dump Segmenta2on viola2on 14 SIGALRM Terminate Timer signal 17 SIGCHLD Ignore Child stopped or terminated 13 Carnegie Mellon Sending a Signal     Kernel sends (delivers) a signal to a des)na)on process by upda&ng some state in the context of the des&na&on process Kernel sends a signal for one of the following reasons:   Kernel has detected a system event such as divide ­by ­zero (SIGFPE) or the termina2on of a child process (SIGCHLD)   Another process has invoked the kill system call to explicitly request the kernel to send a signal to the des2na2on process 14 Carnegie Mellon Receiving a Signal     A des&na&on process receives a signal when it is forced by the kernel to react in some way to the delivery of the signal Three possible ways to react:   Ignore the signal (do nothing)   Terminate the process (with op2onal core dump)   Catch the signal by execu2ng a user ­level func2on called signal handler   Akin to a hardware excep2on handler...
View Full Document

This note was uploaded on 07/03/2013 for the course CS 15-213 taught by Professor Fr during the Fall '07 term at Carnegie Mellon.

Ask a homework question - tutors are online