Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ukma!rutgers!att!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.unix.wizards
Subject: Re: alloca (was: libpw.a)
Message-ID: <8338@chinet.chi.il.us>
Date: 2 May 89 05:02:22 GMT
References: <157@dftsrv.gsfc.nasa.gov> <10013@smoke.BRL.MIL> <8184@chinet.chi.il.us> <1250@frog.UUCP> <564@aablue.UUCP> <1883@thor.acc.stolaf.edu> <15945@rpp386.Dallas.TX.US> <10090@smoke.BRL.MIL> <8261@chinet.chi.il.us> <10939@bloom-beacon.MIT.EDU> <10177@smoke.BRL.
Reply-To: les@chinet.chi.il.us (Leslie Mikesell)
Organization: Chinet - Public Access Unix
Lines: 23

In article <10177@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes:

>>longjmp is evil.

>Well, at least it's worse than "goto".
>Some people have found reasonable (albeit obscure) uses for longjmp.
>I don't use it myself.

Here is a use:
 A print spooler output process accepts commands to print files on a
 pipe from its parent (the scheduler).  An interactive control program
 can cause the scheduler to send signals to the output process.  One
 signal causes the current job to be restarted from the beginning,
 another causes the current job to be discarded and the next command to
 be read from the input pipe.  There are many sub-functions involved
 in the output process.  Using longjmp() out of the signal handler
 allows rapid response from anywhere in the program doing only the
 clean-up needed for the current state.
 Is there any other way to handle a situation like this?  Testing a
 global variable set in the signal handler at all the appropriate
 places would add quite a bit of overhead.

Les Mikesell