Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!ucsd!usc!brutus.cs.uiuc.edu!wuarchive!mailrus!ncar!ico!ico.isc.com!dougm From: dougm@queso.ico.isc.com (Doug McCallum) Newsgroups: comp.unix.wizards Subject: Re: Signals on Sys V Message-ID: Date: 14 Nov 89 20:51:34 GMT References: <1745@calvin.cs.mcgill.ca> <1989Nov13.140120.17775@hcr.uucp> Sender: news@ico.ISC.COM Distribution: na Organization: INTERACTIVE Systems Corporation Lines: 25 In-reply-to: larry@hcr.uucp's message of 13 Nov 89 14:01:20 GMT In article <1989Nov13.140120.17775@hcr.uucp> larry@hcr.uucp (Larry Philps) writes: ... The other interface appeared in R3 and is accessed via the "sigset" system call (same arguments as "signal"). Signal handlers invoked after a sigset behave just like Berkeley signals, that is ensuing signals of the same type are blocked while the signal handler is running. Just put a Almost the same as Berkeley signals but there are some subtle differences. #define signal sigset at the start of your program and see if that fixes the problems. Your program will certainly be more reliable. While the above will work for nearly all cases, it can fail. One of the differences that can catch the unwary, especially when porting BSD software, is that a "longjmp" out of a signal handler will reset the signal to the non-hold state on a BSD system while on a V.3 system you have to explicitly release the hold. This could be important in the case where the stack is being manipulated and the signal handler isn't returned from directly. Its also too bad that the "sighold()" and "sigrelse()" calls only take a signal number and not a mask as with the BSD equivalents.