mangler@cit-vax.Caltech.Edu (System Mangler) (07/09/86)
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@vlsi.caltech.edu seismo!cit-vax!speck "Shrink... I want to kill()." (kill -KILL !) -Arlo Guthrie, "Alice's Restaurant"