Path: utzoo!mnetor!uunet!ncc!alberta!att-ih!ttrdc!levy
From: levy@ttrdc.UUCP (Daniel R. Levy)
Newsgroups: comp.lang.c
Subject: Re: longjmp() from nested signal handlers
Message-ID: <2555@ttrdc.UUCP>
Date: 7 Apr 88 22:13:49 GMT
References: <4548@june.cs.washington.edu> <26739@amdahl.uts.amdahl.com> <3669@sdcc6.ucsd.EDU>
Organization: AT&T, Skokie, IL
Lines: 22

In article <3669@sdcc6.ucsd.EDU>, ix426@sdcc6.ucsd.EDU (Tom Stockfisch) writes:
# In article <26739@amdahl.uts.amdahl.com> nw@amdahl.uts.amdahl.com (Neal Weidenhofer) writes:
# >...  Using longjump from a signal handler ALWAYS results in
# >undefined behavior.
# 
# This *greatly* reduces the value of signals.
# I like to longjmp() back to a main processing loop on SIGINT.  If 
# all I do is set a flag and return,
# then I have to check that flag in a million other places to see if a user
# is trying to get my attention.

On the other hand, this can be desired.  You might be in an iterative procedure
where internal data is in a consistent state only in a few well-defined places.
Even if this isn't so, a careful look at any protracted, iterative sequence
of code that you want to be able to "bust out of" with a signal will reveal
"high traffic" areas where you can put the check; you don't need to put the
check in a "million other places."
-- 
|------------Dan Levy------------|  Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa,
|         an Engihacker @        |  	<most AT&T machines>}!ttrdc!ttrda!levy
|     AT&T Data Systems Group    |  Disclaimer?  Huh?  What disclaimer???
|--------Skokie, Illinois--------|