Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!godot!harvard!seismo!brl-tgr!gwyn
From: gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>)
Newsgroups: net.lang.c
Subject: Re: setjmp/longjmp
Message-ID: <5537@brl-tgr.ARPA>
Date: Thu, 1-Nov-84 06:41:22 EST
Article-I.D.: brl-tgr.5537
Posted: Thu Nov  1 06:41:22 1984
Date-Received: Sat, 3-Nov-84 01:50:09 EST
References: <1@imd.UUCP>
Organization: Ballistic Research Lab
Lines: 13

David Marx posted a nice article about the problems with longjmp'ing
from a signal handler on PDP-11s.  The problem is not quite so bad
on systems with atomic linkage sequences but it is still tricky.

This study reinforces a conclusion I drew long ago:  About all one
should do in response to an asynchronous trap is to set a flag for
periodic testing from the main program loop.  (That gives one MUCH
better control over program internal operation.)  It makes one wonder
what good longjmp is after all...

That was the only article so far that inclines me to surrender the
desire for specifying clean longjmp semantics.  There is not much
point in insisting on that if it is unrealizable.