NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/lang/c/11484

Internet Message Format | 1992-07-22 | 1.7 KB

Path: sparky!uunet!mcsun!fuug!demos!kiae!glas!demos!oracle.us!us.oracle.com!wkaufman
From: [e-mail]
Newsgroups: comp.lang.c
Date: 18 Jul 92 20:46 MDT
Subject: Re: Handling signals (was:  trappin
Sender: Notesfile to Usenet Gateway <[e-mail]>
Message-ID: <[e-mail]>
Nf-ID: #N:[e-mail]:2096584799:001:1278
Nf-From: us.oracle.com!wkaufman    Jul 18 20:46:00 1992
Lines: 27


In article <[e-mail]> [e-mail] (Bill Mitchell) writes:
]
] Looking in PJP's "The Standard C Library", chapter 9, I see that he goes on
] at some length about syncronization and other problems which can occur in
] handling signals.  In part, he says:
]
]   The occurence of a signal introduces a second thread of control within
]   a program.  That raises all sorts of issues about syncronization and
]   reliable operation.  The C Standard promises little in either regard.
]   C programs have been handling signals since the earliest days of the
]   language.  Nevertheless, a portable program can safely take very few
]   actions within a signal handler.

    OK, so this just says that the signal handler should be *very*
careful about touching global variables, right?  Doing nothing,
exit()'ing, or writing to a variable that the main program only reads
from (or vice versa)--these should all be safe, right?

    Is there anything else that would be guaranteed to work?

                                           -- Bill K.

Bill Kaufman,          | "Hush my darling / Be still my darling /
Corporate Lackey       |  The lion's on the phone,..."
[e-mail] |              -- "The Guitar", They Might Be Giants