[comp.unix.wizards] Signal questions

jb10320@uxa.cso.uiuc.edu (Jawaid Bazyar) (06/29/91)

  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?)

  The manpages don't go into detail, and none of the generic Unix books I
have access to do either.  I'm working on a multithread system for PCs
and want to handle software signals just like Unix, so I need to implement
all this garbage.
  Thanks in advance...

--
Jawaid Bazyar               |  "Twenty seven faces- with their eyes turned to
Graduated!/Comp Engineering |    the sky. I have got a camera, and an airtight
bazyar@cs.uiuc.edu          |     alibi.."
   Apple II Forever!        |  I need a job... Be privileged to pay me! :-)

mouse@thunder.mcrcim.mcgill.edu (der Mouse) (07/01/91)

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