Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!ernie.Berkeley.EDU!jas
From: jas@ernie.Berkeley.EDU (Jim Shankland)
Newsgroups: comp.unix.wizards
Subject: Re: Avoiding longjmp
Message-ID: <29105@ucbvax.BERKELEY.EDU>
Date: 8 May 89 18:14:41 GMT
References: <13624@ncoast.ORG>
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: jas@ernie.Berkeley.EDU (Jim Shankland)
Organization: University of California, Berkeley
Lines: 21

In article <13624@ncoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery) writes:
>Might I suggest that the proper method for dealing with asynchronous signals
>of any sort without "longjmp" or its equivalent has been known for some time
>now.  It's called an event loop.

At the risk of getting into a "dessert topping/floor wax" argument:
the proper method for dealing with asynchronous signals is light-weight
processes (a.k.a. threads).  Forget signal handlers altogether:  you
dedicate a thread to signal handling by having it call a modified
pause().  A signal causes the pause()'d thread to run.  It can
abort its sister lwp's and/or start new ones, if it desires.
Obviously, you also need inter-thread synchronization primitives.

This approach has the advantage of making the parallelism implicit
in signal handlers explicit, allowing problems like heap corruption due
to signal in mid-malloc to be confronted head-on.

Jim Shankland
jas@ernie.berkeley.edu

"Blame it on the lies that killed us, blame it on the truth that ran us down"