Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!mouse
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Newsgroups: comp.unix.wizards
Subject: Re: Signal questions
Message-ID: <1991Jun30.232930.8977@thunder.mcrcim.mcgill.edu>
Date: 30 Jun 91 23:29:30 GMT
References: <1991Jun29.000424.21255@ux1.cso.uiuc.edu>
Organization: McGill Research Centre for Intelligent Machines
Lines: 34

In article <1991Jun29.000424.21255@ux1.cso.uiuc.edu>, jb10320@uxa.cso.uiuc.edu (Jawaid Bazyar) writes:

>   I've got some bizarre questions about signal handling.  

> 1) What exactly does the kernel do to stack up signal requests to a
>    process?

> 2) How does the kernel feed signals to a process if there are more
>    than 1 waiting?  (Does it wait for one to finish then give the
>    next, or what?)

Both of these are system-dependent.  Those machines for which I know
the answers all do it basically the same way.  (1) is handled by
keeping a bitmask for each process indicating which signals are pending
for delivery to that process.  (2) is trickier.  Looking at the code
for 4.3 gives me the impression that the lowest-numbered signal is
delivered.  Next time the process enters the kernel (eg, when its
quantum expires or it does a syscall), the lowest-numbered pending
signal that isn't blocked by the then-current signal mask will be
delivered.  This will repeat until there are no more signals pending
and unblocked.

Any program that depends on the details of the answer to (2) is
horribly system-dependent and you shouldn't worry about precisely
matching your implementation to any specific UNIX system's.  However,
signals have always been able to interrupt other signal handlers, and
on some systems they can interrupt instances of the same signal's
handler even by default.

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu