Signal Handling in Unix
Signal Handling in Unix
user programs
user Level kernel Level
trap
libraries
system call interface
memory management
hardware control
System Calls
Provide an interface between a process an d the operating system. Generally availabl e as assembly-language instructions UNIX system calls maybe invoked directly from a C or C++ program System calls for modern Microsoft Window s platforms are part of the Win32 applicati on programmer interface (API), which is av ailable for use by all the compilers written for Microsoft Windows
fork
Swap out
Swap out
Swap in
The process priority, user-mode scheduling priority, recent CPU utilization, and amount od of time spent sleeping
Signal State
Timer : Real-time timer and CPU-utilization counters Event Descriptor Realted Process Ids Serveral User IDs & Group IDs : uid, euid, gid, egid
write
Permission modes field masks mode setting on the files the process creats.
Process Control
Control of Process Context
fork : create a new process exit : terminate process execution wait : allow parent process to synchronize its execution with the exit of a child process exec : invoke a new program brk : allocate more memory dynamically signal : inform asynchronous event
Process Creation
Process Creation
Signals
Informs the occurrence of asynchronous event.
from process to process : kill system call. from kernel to process internally. 64 Signals
Treatment of Signals
How the kernel sends a signal to a process. How the process handles a signal How a process controls its reaction to the signal
sets a bit in the signal field in process table entry. process can remember different type of signal. process can not remember how many signals it receives of particular type. u area contains an array of signal-handler fields. kernel stores the address of the user-function in the field.
about to return from kernel mode to user mode enters or leaves the sleep state at a suitably low scheduling priority.
Handle Signals
Handling Signals
Handling Signals
kernel handles signals in the context of the process that received signals. process must run to handle signals exit(default action) ignores signals executes a particular user function
Three Cases
specify special action to take on receipt of certain signal oldfunction = signal(signum, function);
signum : signal number function : the address of function to invoke on receipt of signal
0 : exit 1 : ignore
12
13
kill(pid,signum)
pid : set of processes to receive the signals signum : signal number being sent
Failure
if the sending process does not have effective user ID of super user, or its real user ID or effective user ID do not match the real or effective user ID of the receiving process.
14
Kernel sends the signal to the 5 even processes that did not reset their process group 5 odd processes continue to loop
setpgrp(); for(i=0; i<10; i++) { if (fork()==0) { /* child proc */ if ( i & 1 ) setpgrp(); printf(pid=%d pgrp=%d\n, getpid(), getppid()); pause(); } } kill(0,SIGINT); }
15
Process Termination
exit system call
exit(status);
status : the value returned to parent process
call exit explicitly or implicitly(by startup routine) at the end of program. kernel may invoke internally on receipt of uncaught signals. In this case, the value of status is the signal number.
16
synchronize its execution with the termination of a child process pid = wait(stat_addr);
pid : process id of the zombie child process
17
18
most processes on typical system associated with users at a terminal not associated with any users do system-wide functions administration and control of networks, execution of timedependent activities, line printer spooling, and so on run at user mode and make system calls to access system service like user process execute only in kernel mode process 0 spawns kernel process, such as page-reclaiming process vhand, and then becomes the swapper process extremely powerful, not flexible
20
Daemon Process
Kernel Process