handle_softirq stuff,reschedule stuff,before doing a RESTORE_ALL,as explained

before. The do_signal routine works by dequeuing the signals,one after the

another, to send the first possible signal.Dequeueing of signals is logical only

if some fragment has queued the signal.This signal queue,and siginfo management

is done in linux/kernel/signal.c.When the process receives a signal either

through a notify_parent or a kill,the signal is queued up using send_siginfo

defined in kernel/signal.c. This routine collects the signal,and queues up the

signal in the sigpending structure of the process. The validity of the signal is

also checked by bad_signal routine,before queueing up the signal. Some

conclusions are arrived at,by the signal_type routine if the handlers fall in

SIG_DFL, or SIG_IGN category. There is a special treatment for SIGCHLD, for a

SIG_IGN, which never gets ignored. This according to me,is double

standards,because the caller gets away if he has a SIG_IGN handler for

SIGCHLD,but gets penalised (Zombies galore) if he forgets to install the

handler. (a ret.value of 1 instead of 0 in the signal_type routine for

{SIGCHLD,SIG_DFL } case should eradicate Zombies.) In fact,the do_signal routine

has a special check for {SIGCHLD,SIG_IGN},and does the job of reaping the child

by calling sys_wait4 and thus prevents useless Zombies from piling up,with

task->state = TASK_ZOMBIE. Please note that Zombies dont clog resources, as

when a process exits, exit_notify (linux/kernel/exit.c), performs all cleanup

with respect to a tasks resources,before setting the task state to TASK_ZOMBIE.

The notify_parent (linux/kernel/signal.c) call in exit_notify,queues up the

tasks exit_signal(task->exit_signal) which has a default value of SIGCHLD on

a \"fork.\" This function fills up the siginfo structure for the signal to be

queued,queues up the signal,calling send_siginfo,and wakes up the parent (and

all the others in its thread_group (struct list_head thread_group) ) blocking on

its wait_chldexit wait_queue.

Explanation of sys_wait4 is done only to confirm that Zombies do not

claim resources, as most of them __wrongly__ believe:

The sys_wait4 syscall,which is responsible for reaping the child, processes

its child list, by looping through the task->p_osptr (older sibling pointer),

starting from task->p_cptr (youngest child), based on a set of flags. If it