Xref: utzoo comp.arch:4282 comp.lang.c:8974 comp.unix.wizards:7628
Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!nrl-cmf!mailrus!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!bbn!rochester!PT.CS.CMU.EDU!cadre!pitt!darth!formtek!ditka!csanta!greg
From: greg@csanta.UUCP (Greg Comeau)
Newsgroups: comp.arch,comp.lang.c,comp.unix.wizards
Subject: Re: longjmp() out of nested signal handlers
Message-ID: <122@csanta.UUCP>
Date: 6 Apr 88 17:30:56 GMT
References: <4609@june.cs.washington.edu>
Reply-To: greg@csanta.UUCP (Greg Comeau)
Organization: Comeau Computing, Richmond Hill, NY
Lines: 37

In article <4609@june.cs.washington.edu> pardo@uw-june.UUCP (David Keppel) writes:
>
>According to both my Springer Verlag C book and to Chris Torek, the
>dpANS document says that longjmp() out of nested signal handlers is
>undefined.  I would like to know why this is; the reason is very
>non-obvious to me.

The problem that occurs with longjmp() is not within the function itself,
but with any side-effects that may occur because of the longjmp().
(This BTW, only happens to be spelled out in dpANSI, but has been true
even without that being said since its first implementations).  For instance,
within library functions that you don't have source code to (or even your own
routines that you do have source code to), a given routine may be setting an
external variable for later use or maybe let's say as a semaphore.  If a
longjump occurs after the setting of the variable but before it's put to any
use, then you're in trouble.

Another quite obtuse reason is that the corresponding setjmp() may be
called in a line of code where it was part of a subexpression.  Yickie
poo for that one!

And of course, their is the always problamatic code that longjmp's
back to a routine that had made use of some register variable, variable
that were made into registers by the compiler or jumping to a routine
that has already returned!

This is all about the dangers of longjmp in general though and does not
address nested signal handlers specifically, although this does present
problems for them.  Especially when it involves global variables or
ensuring that some event has completed before processing the second
signal (regardless of whether it is the same or not).

The main gist though is that a signal handler should do what it has to do
as quickly as possible.  Also of concern is the way signal are handled on
a given machine.  Whatever particular things it does to handle the interrupt
must be able to be reversable for normal return of the interrupt.
Allowing longjmp's to occur in a nested handler could make the signal
cleanup a real mess.