More on subtle properties of signals

[System Mangler]

Thanks to all who responded to my query about pipe writes
interrupted by caught signals.	It turns out that writes
of less than PIPSIZ (4096 on BSD) are atomic; instead of
sending a little at a time, Unix waits until the whole
write will fit (or pipe is empty) before sending anything.
So, if you write less than PIPSIZ, errno=EINTR means that
nothing was sent.  It does the right thing!

Now some more subtle points ... (aren't these documented
anywhere)?

What happens if a process receives signals x, y, and z
(different signal numbers) in such rapid succession that
the process doesn't get run time between them?	Could
one of the signal routines fail to be called?  Is there
a "signal present" bit for each kind of signal?

What happens if a signal is caught during the execution
of longjmp()?  Does longjmp guarantee that the stack stays
consistent enough to have a frame pushed onto it, or not?
The catch routine is only going to set a (global) flag.

Let's suppose that I have a signal catch routine that
kill()s another process.  The other process then gets
cpu time, does its thing, and sends a signal back to the
first process.	If the first process hasn't gotten any
cpu time since calling kill(), it may not have returned
from the signal catch routine yet.  What happens now?
Does the signal catch routine get re-entered, does the
kernel wait for it to return, does the new signal get lost?

Is it possible to wait for a signal in a race-free manner
without use of setjmp/longjmp?	(On System V)?	If so, HOW?

Thanks, as they say, in advance (as I am hopelessly far
behind in responding to mail).

Don Speck	speck at vlsi.caltech.edu	seismo!cit-vax!speck

"Shrink... I want to kill()."  (kill -KILL !)
	-Arlo Guthrie, "Alice's Restaurant"