signals interrupting IPC functions

[The Beach Bum]

In article <548 at micropen> dave at micropen (David F. Carlson) writes:
} In article <216 at ISIDAPS5.UUCP>, mike at ISIDAPS5.UUCP (Mike Maloney) writes:
} > When a call to msgrcv terminates because of the arrival of a signal,
} > is it possible that a message on the queue could be lost?
} 
} RTFM:  signal(2):
} "When a signal to be caught occurs during read(2), a write(2), an open(2),
} an ioctl(2) or system call to a slow device, ... during pause(2) or wait(2),
} ... the system call may return -1 to the calling process with errno set
} to EINTR."
} 
} No mention of msgrcv(2) at all.  I believe since it is not mentioned, it
} is guaranteed not to occur.

incorrect.  the page for msgrcv(2) states that if IPC_NOWAIT is false in
the call to msgrcv() and a signal which is set to be received occurs, then
msgrcv() returns -1 and errno == EINTR.

this behavior is going to be true, in general, of all system calls which
can be expected to block for more than a brief period of time.  the only
requirement that a system call be interuptable is that it does not sleep
at less than PZERO.

to answer david's question - not likely unless there is a race in the
kernel i've never seen posted to the net.  the two situations involve
either the process sending itself a signal [ SIGALRM being the only one
it can ] or some other process sending it a signal.

some other process can only send it a signal if no message is ready to be
read [ more or less ], so the message, which isn't being processed
because it
doesn't exist, can't be lost.

the only signal a process can send itself while blocked in a system call
is SIGALRM.  if the process is blocked at the moment, no big deal, same
situation as above.  otherwise, the exact result depends on the scheduler
and how it works.  but generally i'd say the answer is no.
-- 
John F. Haugh II (jfh at rpp386.Dallas.TX.US)                   HASA, "S" Division

      "Why waste negative entropy on comments, when you could use the same
                   entropy to create bugs instead?" -- Steve Elias