Class Note for EECS 678 with Professor Kulkarni at KU 2
Class Note for EECS 678 with Professor Kulkarni at KU 2
Popular in Course
Popular in Department
This 18 page Class Notes was uploaded by an elite notetaker on Friday February 6, 2015. The Class Notes belongs to a course at Kansas taught by a professor in Fall. Since its upload, it has received 16 views.
Reviews for Class Note for EECS 678 with Professor Kulkarni at KU 2
Report this Material
What is Karma?
Karma is the currency of StudySoup.
You can buy or earn more Karma at anytime and redeem it for class notes, study guides, flashcards, and more!
Date Created: 02/06/15
Introduction to Unix Signals Michael Jantz Prasad Kulkarni Introduction This lab is an introduction to signals in Unix systems Last week39s lab used signals but you will not need to have completed last week39s lab to understand this lab Grab the starter code from the website httppeopleeecskuedumjantz678labslab10Iab10targz Untar it make it tag it if you please tarxvzflab10targz cd ab10 make ctags R Signals A signal is a short message that may be sent to a process or a group of processes The only information given to a process is usually the number identifying the signal there is no room in standard signals for arguments a message or other accompanying information Signals serve two main purposes To make a process aware that a specific event has occurred To cause a process to execute a signal handler function included in its code Interrupts vs Signals Signals and interrupts are very similar in their behavior The difference being interrupts are sent to the operating system by the hardware signals are sent to the process by the operating system or other processes In a sense signals can be thought of as an interrupt in software However note that signals have nothing to do with softirqs often called software interrupts These are interrupts sent by the hardware but whose handling is deferred Signal Disposition Each signal that can be delivered in Linux has a current disposition which determines how the process behaves when it is delivered the signal A process can change the disposition of a signal using various system calls Using these system calls a process can elect one of the following behaviors to occur on delivery of the signal perform the default action ignore the signal or catch the signal with a signal handler a programmerdefined function that is automatically invoked when the signal is delivered The entries in the Action column of the table on the following slide specify the default disposition for each signal as follows Term Default action is to terminate the process Ign Default action is to ignore the signal Core Default action is to terminate the process and dump core see core5 Stop Default action is to stop the process Cont Default action is to continue the process if it is currently stopped Signal Value Action Comment SIGHUP 1 Term Hangup detected on controlling terminal or death of controlling process SIGINT 2 Term Interrupt from keyboard SIGQUIT 3 Core Quit from keyboard SIGILL 4 Core Illegal Instruction SIGABRT 6 Core Abort signal from abort3 SIGFPE 8 Core Floating point exception SIGKILL 9 Term Kill signal SIGSEGV 11 Core Invalid memory reference SIGPIPE 13 Term Broken pipe write to pipe with no readers SIGALRM 14 Term Timer signal from alarm2 SIGTERM 15 Term Termination signal SIGUSR1 301016 Term Userdefined signal 1 SIGUSR2 311217 Term Userdefined signal 2 SIGCHLD 201718 Ign Child stopped or terminated SIGCONT 191825 Cont Continue if stopped SIGSTOP 171923 Stop Stop process SIGTSTP 182024 Stop Stop typed at tty SIGTTIN 212126 Stop tty input for background process SIGTTOU 222227 Stop tty output for background process Using Signals with the Shell Open Nachos under gdb and issue the following commands bash32 gdb userprognachos gdb b SchedulerReadyToRun gdb rx testnicefree gdb call Debuglnitquotalquot gdb call debugShowReadyListreadyList Now consider you want to go look at the Nachos code You could exit gdb look at the code and then restart your debugging session but this clearly requires a lot of retyping commands You could open a new terminal but then you have to find the Nachos directory again and have to deal with switching between terminals A better solution use signals Multiple Jobs in One Shell You can stop the gdb process without losing what you39ve already done by issuing the SIGTSTP signal This is done with ctrlz 1 Stopped gdb userprognachos Now open an editor in that same terminal to the schedulercc file you could open a couple buffers if you want to make this interesting bash32 vim threadsschedulercc And stop this process 2 Stopped vim threadsschedulercc We now are managing a shell session with multiple jobs Type jobs bash32 jobs 1 Stopped gdb userprognachos 2 Stopped vim threadsschedulercc Foreground and Background To bring gdb back to the foreground do bash32 fg 1 fg n brings the nth process as listed when you type jobs to the foreground fg with no arguments will bring the current process the one with the next to it when you type jobs to the foreground The next command you type will be issued to the gdb process press enter to see the prompt Enter any commands you want and stop the gdb process again ctrlz You can bring the vim process to the foreground if you like You39ll notice the session is exactly how you left it bg operates the same way as fg except that it runs the selected job in the background as if you had started it with amp as opposed to the foreground 9 Killing Jobs Now let39s finish this example up You can kill jobs using the kill command bash32 kill 1 1 Stopped gdb userprognachos bash32 jobs 1 Done gdb userprognachos 2 Stopped vim threadsschedulercc By default kill delivers a TERM signal same as ctrlC to the job you specify Notice when you try to kill vim the shell doesn39t let you This is because vim does not terminate immediately when it receives the TERM signal in fact it simply tells the userto exit the conventional way wq You can see this by running vim in the foreground and issuing a TERM signal with ctrlC How to get around this There is a special signal called kill that the kernel handles that user processes cannot override lssue vim the kill signal bash32 kill KLL 2 At first it may not seem like it worked But press enter a couple times and you39ll see that vim has in fact been killed 10 Signal Handlers How did vim ignore the TERM signal For most signals user processes are allowed to define signal handlers to override the signal39s default disposition The KILL and STOP signals are the exceptions as they are caught by the operating system This is why we used KILL to kill the vim process In this lab we are going to use signal handlers to respond to a few common signals in a unique way 11 signalsc This file contains two functions you will use as signal handlers catchint keeps a count of how many times it has been invoked up to some threshold When this count passes CTRLCTHRESHOLD it asks the user if he or she wants to exit If the user responds in the affirmative the program exits catchsuspend prints out the current ctrlccount In this lab we will use these functions to implement a program that accepts a number of INT signals the signal generated by ctrlC before asking the user if he or she would like to really exit lssuing the TSTP signal the signal generated by ctrlZ prints the number of times the user has issued the INT signal since the user was last prompted to exit You will use the system calls on the following slides 12 Pause and Sigaction int pause void Causes the calling process to wait until any signal is received Should be called in a loop in the main function int sigaction int signum const struct sigaction act struct sigaction odact Assigns a handler for a signal according to a sigaction struct signum is the number of the signal you would like to assign a handler for The macros SIGINT and SIGTSTP can be used forthis lab act is a pointerto the sigaction struct specifying how the signal should be handled see the following slide for a more indepth explanation oldact is a pointer to the sigaction struct that was used for this signal before this call Forthis lab we don39t care about this information Simply pass in NULL to ignore it 13 struct sigaction The sigaction struct has the following structure struct sigaction void sahandlerint void sasigactionint siginfot void sigsett samask int saflags void sarestorervoid sahandler is a pointer to the handler function that will be called when the signal is received Use this when the handler does not need additional information other than the signal number You will use this to store a pointer to each handler function sasigaction is also a pointer to a handler function Use this when your handler needs more information than just a signal number see sigaction man page for more details You will not need this for this lab samask is the set of signals you wish to mask ie block during execution of the signal handler You will need to use this for this lab saflags allows you to set various options when handling the signal You will not need to change the default settings for this lab 14 sarestorer is obsolete You will not need this for this lab Modifications Modify signalsc to implement the behavior described on slide 12 You will not need to modify the signal handlers One last system call you may want to use int sigfillsetsigsett set sigfillset initializes the set pointed to by set to be full ie it includes all signals Continue to the next slide when you39re confident your simple program is working 15 Adding a Timeout Suppose users of this program almost always mean to exit when they issue 5 INT signals Most of the time users rememberto type 39Y39 and actually exit the program but a small percentage of the time the user simply leaves the terminal and forgets to type 39Y39 think of how logging out of the machines here at the lab works In this situation it might make sense to add a timeout which performs the exit if there is no response from the user for some time As the final part of this lab we will add a timeout to exit our program if the user forgets to type a response when prompted 16 Alarm The alarm system call is a convenient way to implement timeouts unsigned int alarmunsigned int seconds alarm arranges for a SIGALRM signal to be delivered to the calling process in seconds seconds You should initiate an alarm to go off after so many seconds after the user has been prompted to exit You will have to unmask the SIGALRM signal when initializing the SIGINT signal handler so SIGALRM will be handled when the timeout occurs Use sigdelset to remove SIGALRM from the masked set int sigdelsetsigsett set int signum You should define a signal handler for the SIGALRM signal This handler should terminate the process if the user has not entered a response to the exit prompt 17 Final Output bash32 signas l CquotCquotCquotCquotC Really Exit Yn n Continuing l CquotCquotCquotZ So far 39339 CtrIC presses were counted l CquotZ So far 39439 CtrIC presses were counted l C Really Exit Yn n Continuing l CquotCquotCquotCquotC Really Exit Yn Usertaking too long to respond Exiting 18
Are you sure you want to buy this material for
You're already Subscribed!
Looks like you've already subscribed to StudySoup, you won't need to purchase another subscription to get this material. To access this material simply click 'View Full Document'