jdubb@bucsf.bu.edu (jay dubb) (03/18/91)
I am posting this for a friend of mine who doesn't have access to USENET, so please respond directly to mlevin@jade.tufts.edu. I have recvfrom() call in my code that attempts to read a UDP socket message, and is returning -1 and setting errno to EINTR - interrupted system call (as far as I can tell, this is the signal caused by one of the child processes dying). What exactly does an interrupted recvfrom() do? Can I temporarily disable signal delivery around the call (but making sure the signal is delivered after the call completes)? If so, is this a good idea, provided I want to catch the message, and the signal also? If not, what should I do? Thanks in advance. Mike Levin (mlevin@jade.tufts.edu)
mouse@thunder.mcrcim.mcgill.edu (der Mouse) (03/26/91)
In article <77135@bu.edu.bu.edu>, jdubb@bucsf.bu.edu (jay dubb) writes: > I have recvfrom() call in my code that attempts to read a UDP socket > message, and is returning -1 and setting errno to EINTR - interrupted > system call (as far as I can tell, this is the signal caused by one > of the child processes dying). What exactly does an interrupted > recvfrom() do? Nothing, I would hope and expect. It depends on your system, of course (you don't say what sort of machine or OS variant is in question). > Can I temporarily disable signal delivery around the call (but making > sure the signal is delivered after the call completes)? Since recvfrom() is a socket call, I assume you're on a Berkeley variant, in which case you should have sigblock() and sigsetmask(), which should allow precisely that. > If so, is this a good idea, provided I want to catch the message, and > the signal also? Unless you have experiments showing it doesn't work, I would recommend just going back and doing the recvfrom() again when you get EINTR. If that is known to fail, blocking the signal in question is reasonable. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu