Page 282 - DCAP403_Operating System

Unit 13: Case Study: Linux

structures pointed at by the task_struct for each process. Amongst other things it contains either Notes

the address of a routine that will handle the signal or a flag which tells Linux that the process
either wishes to ignore this signal or let the kernel handle the signal for it. The process modifi es
the default signal handling by making system calls and these calls alter the sigaction for the
appropriate signal as well as the blocked mask.
Not every process in the system can send signals to every other process, the kernel can and super
users can. Normal processes can only send signals to processes with the same uid and gid or to
processes in the same process group. Signals are generated by setting the appropriate bit in the

task_struct’s signal field. If the process has not blocked the signal and is waiting but interruptible
(in state Interruptible) then it is woken up by changing its state to Running and making sure that
it is in the run queue. That way the scheduler will consider it a candidate for running when the
system next schedules. If the default handling is needed, then Linux can optimize the handling
of the signal.

Example: If the signal SIGWINCH (the X window changed focus) and the default handler
is being used then there is nothing to be done.

Signals are not presented to the process immediately they are generated., they must wait until the
process is running again. Every time a process exits from a system call its signal and blocked fi elds
are checked and, if there are any unblocked signals, they can now be delivered. This might seem
a very unreliable method but every process in the system is making system calls, for example to
write a character to the terminal, all of the time. Processes can elect to wait for signals if they wish,
they are suspended in state Interruptible until a signal is presented. The Linux signal processing
code looks at the sigaction structure for each of the current unblocked signals.
If a signal’s handler is set to the default action then the kernel will handle it. The SIGSTOP signal’s
default handler will change the current process’s state to Stopped and then run the scheduler to
select a new process to run. The default action for the SIGFPE signal will core dump the process
and then cause it to exit. Alternatively, the process may have specified its own signal handler.

This is a routine which will be called whenever the signal is generated and the sigaction structure
holds the address of this routine. The kernel must call the process’s signal handling routine and
how this happens is processor specific but all CPUs must cope with the fact that the current

process is running in kernel mode and is just about to return to the process that called the kernel
or system routine in user mode. The problem is solved by manipulating the stack and registers of
the process. The process’s program counter is set to the address of its signal handling routine and
the parameters to the routine are added to the call frame or passed in registers. When the process
resumes operation it appears as if the signal handling routine were called normally.
Linux is POSIX compatible and so the process can specify which signals are blocked when a
particular signal handling routine is called. This means changing the blocked mask during the
call to the processes signal handler. The blocked mask must be returned to its original value

when the signal handling routine has finished. Therefore Linux adds a call to a tidy up routine
which will restore the original blocked mask onto the call stack of the signalled process. Linux
also optimizes the case where several signal handling routines need to be called by stacking them
so that each time one handling routine exits, the next one is called until the tidy up routine is
called.

13.8.2 Pipes

The common Linux shells all allow redirection. For example

$ ls | pr | lpr

LOVELY PROFESSIONAL UNIVERSITY 275