Here's a job control conundrum for you.

[Steven W. Orr]

On Wednesday, Apr 11th 2007 at 18:19 -0400, quoth Ben Scott:

=>On 4/11/07, Steven W. Orr <steveo at syslang.net> wrote:
=>> => Hmmm, one correction, though: That shows the signal was *sent*.  You
=>> =>need to use "--wait" to have killall wait and tell you if/when the
=>> =>signal was *received*.
=>> 
=>> --wait doesn't return if the signal is received. ... --wait will loop around
=>> looking to see if the process actually disappears.
=>
=> Oh.  Silly me, I figured the "--wait" option invoked wait(2).
=>Although now that I think about it, it couldn't, could it?  wait(2) is
=>only good for child processes, right?  Phooey.

There's a word I haven't heard in a while. 

=>
=>> There's no delay between the send and receive of a signal.
=>
=> My terminology might be wrong, but I was referring to the fact that
=>signals are not processed synchronously.  For example, if a process is
=>in the "interruptible sleep" state, it will not receive *any* signals
=>until the system call it's blocked on returns.  Even SIGKILL will be
=>delayed.  Yes?

Assuming we're in a modern sigaction environment instead of an old signal 
environment, all signals will queue up if you have set SIG_BLOCK except 
for SIGKILL which always goes right through.

Also, "interruptable sleep state" is a concept that depends on what you're 
doing. Some system calls are restartable, some are resumable. A plain old 
pause is dependant on your sigmask and a sigsuspend takes its own mask.

The best writeup of signal stuff that I've seen is in the OReilly book 
called UNIX Systems Programming for SVR4 (Nutshell Handbook). Other 
descriptions never punched the conceptual stuff through to me as well.