Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: Behaviour of setjmp/longjmp and registers
Message-ID: <9536@smoke.BRL.MIL>
Date: 28 Jan 89 06:57:40 GMT
References: <25@torsqnt.UUCP> <8867@bloom-beacon.MIT.EDU> <9480@smoke.BRL.MIL> <470@maxim.ERBE.SE>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 18

In article <470@maxim.ERBE.SE> prc@maxim.ERBE.SE (Robert Claeson) writes:
>Now, make this portable and non  CPU-intensive. If you think the
>algorithm needs to be changed, just tell me.

I assume you're not using stdio to do this, since longjmping from
a signal handler is unsafe if a stdio routine was active at the
time of the alarm.  A SVID-conforming UNIX provides several ways
to do the sort of thing you're attempting, for example using VMIN
and VTIME which obviate the need for SIGALRM.  Or, you could just
set a global flag in your alarm handler and return, since a SVID-
conforming UNIX will abort a read() from a terminal when the alarm
occurs.  By testing for EINTR after the read() returns, and using
the global flag as additional verification, you can make the main
control logic do the right thing.

There is no fully portable way to do what you're attempting, and
using longjmp is not a solution because it is unreliable in this
context.