treed@dasys1.UUCP (Timothy Reed) (11/30/88)
I don't have access to a 5.3.1 system, but I understand that signal() has been replaced by a new set of signal handlers. Could someone kindly mail me a man page (I think that the replacement is sigset()?) or a brief summary of snytax and usage (and signals!) - doing so will make my life much easier!!! Thanks! Timothy Reed -- NAME : Timothy Reed PHONE: 7188527454 UUCP : ..!cmcl2!phri!dasys1!treed || ..!uunet!dasys1!treed MAIL : 300 Union St^MBkyn, NY^M11231
evil@arcturus.UUCP (Wade Guthrie) (12/03/88)
In article <7997@dasys1.UUCP>, treed@dasys1.UUCP (Timothy Reed) writes: > I don't have access to a 5.3.1 system, but I understand that signal() > has been replaced by a new set of signal handlers. Could someone kindly While we're talking about signal(), I got the impression that the behavior of signal handling functions was operating system dependent (e.g. AT&T UNIX causes the programmer installed signal handler to be replaced by the system routine when the signal in question occurs, but BSD UNIX does not replace the programmer's routine). I noticed in an article about the dpANS (am I correct in assuming that this means something like the draft of the proposed ANSI standard?) the signal function -- how is the behavior of this specified, is it specified in a portable fashion or do they leave it up to the operating system? Enquiring minds want to know Wade Guthrie Rockwell International Anaheim, CA (Rockwell doesn't necessarily believe / stand by what I'm saying; how could they when *I* don't even know what I'm talking about???)
gwyn@smoke.BRL.MIL (Doug Gwyn ) (12/04/88)
In article <2914@arcturus> evil@arcturus.UUCP (Wade Guthrie) writes: >I noticed in an article about the >dpANS (am I correct in assuming that this means something like the >draft of the proposed ANSI standard?) the signal function -- how is the >behavior of this specified, is it specified in a portable fashion or do >they leave it up to the operating system? ANSI C will specify signal() and minimal associated semantics for it, just enough for applications to have a "fighting chance" at portable use of signals. Technically there are loopholes big enough to drive an M1A1 through, but it is to be hoped that most implementations will strive to provide usable signal facilities. POSIX (IEEE Std 1003.1) specifies a different interface that is considerably more robust, so if you need to do much more than trap SIGINT to set an "interrupt requested" shared flag (of type "volatile sig_atomic_t"), you're advised to use the POSIX facilities instead of signal(). ANSI C signal() is specified so that either the traditional (until 4.2BSD changed it) reset to SIG_DFL upon entry to the handler occurs, or some form of "blocking" (intended to be the POSIX reliable signal mechanism) is performed for the signal that dispatched the handler. Thus, portable applications need to invoke signal(sig,handler) as the first thing in a signal handler, to reduce the window of vulnerability, if the signal could occur during execution of the handler (not all signals fall into that category.) On reliable-signal systems, that will be redundant but harmless.
rja@edison.GE.COM (rja) (12/06/88)
In article <9055@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn ) writes: > ANSI C will specify signal() and minimal associated semantics for it, > just enough for applications to have a "fighting chance" at portable > use of signals. Technically there are loopholes big enough to drive > an M1A1 through, but it is to be hoped that most implementations will > strive to provide usable signal facilities. POSIX (IEEE Std 1003.1) > specifies a different interface that is considerably more robust, so > if you need to do much more than trap SIGINT to set an "interrupt > requested" shared flag (of type "volatile sig_atomic_t"), you're > advised to use the POSIX facilities instead of signal(). I am unclear about the part above where it seems to state that the IEEE 1003.1 POSIX standard and ANSI C standard are in conflict. I keep reading in IEEE Computer and the earlier published 1003.1 draft that they were coordinating their effort with the X3J11 effort to make sure the 2 were compatible. Ran rja@edison.ge.com