Xref: utzoo comp.arch:4241 comp.lang.c:8884 comp.unix.wizards:7565
Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!mailrus!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!uw-beaver!uw-june!pardo
From: pardo@june.cs.washington.edu (David Keppel)
Newsgroups: comp.arch,comp.lang.c,comp.unix.wizards
Subject: longjmp() out of nested signal handlers
Message-ID: <4609@june.cs.washington.edu>
Date: 5 Apr 88 00:56:11 GMT
Reply-To: pardo@uw-june.UUCP (David Keppel)
Organization: U of Washington, Computer Science, Seattle
Lines: 31


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.

This seems (possibly) like a really common occurance.  For instance in
"vi", ^C is supposed to take you back to the main loop from wherever you
are, and it uses a longjmp() to do this (I think).  When "autowrite" is
set, sending a ^Z causes changes to be written before "vi" is suspended.
Sending ^C during ^Z is a well-defined operation and appears to be
implemented by longjmp() out of nested signal handers, and would be
broken by the new standard.

This is at minimum a bothersome restriction from the programmers' view.
I assume that there is some good reason for this restrcition either
from the compiler-writer's view or because of some hardware
organizations.  Somebody locally suggested that it might have something
to do with machines that use a seperate stack for signal handlers, but
so far neither of us has had any ideas about why this (or anything
else, for that matter) would cause such a restriction.

Doug Gwyn suggests that this might have something to do with trying
to wrap multiple levels of trampoline code around longjmp(), but
doesn't have the gory details available.

So far only Doug Gwyn and Chris Torek have responded to my first
posting.  If you understand, please write!

	    ;-D on  ( Coming soon: ping-pong code )  Pardo

    pardo@june.cs.washington.edu   ..!ucbvax!uw-beaver!uw-june!pardo