Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 (Tek) 9/28/84 based on 9/17/84; site orca.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!bellcore!decvax!tektronix!orca!andrew
From: andrew@orca.UUCP (Andrew Klossner)
Newsgroups: net.unix-wizards
Subject: Re: alarm code
Message-ID: <1389@orca.UUCP>
Date: Mon, 11-Mar-85 02:29:34 EST
Article-I.D.: orca.1389
Posted: Mon Mar 11 02:29:34 1985
Date-Received: Wed, 20-Mar-85 04:01:31 EST
Organization: Tektronix, Wilsonville OR
Lines: 39

> Although this solution to the problem may be sound, this method of implementing
> it is, er... dumb (to say the least).  The following implementation is much
> easier to understand, simpler and (Oh wow!) portable:
> 
> 
> 		int (*foo)();
> 		int pause();
> 			...
> 		{
> 			...
> 			/* Point at the pause() call */
> 			foo = pause;
> 			/* Set up alarm */
> 			alarm(1);
> 			/* Actually do pause (well, maybe) */
> 			(*foo)();
> 			/* Proceed merrily along */
> 		}
> 
> 		int null()
> 		{}	/* Do nothing function */
> 
> 		alarm_signal_handler()
> 		{
> 			foo = null;
> 		}

It also doesn't solve the problem.  Consider this sequence of events:
alarm(1) is called; now we begin executing the code for (*foo)() as
follows: fetch the contents of foo() and do the subroutine-call
instruction.  Before the first instruction of the pause() subroutine is
executed, the signal goes off.  Away we go to alarm_signal_handler
which changes the value of "foo".  Then back to the pause routine,
where we do the Unix call for pause, which waits forever.

The portable way to solve this problem is to use setjmp/longjmp.

  -- Andrew Klossner   (decvax!tektronix!orca!andrew)       [UUCP]
                       (orca!andrew.tektronix@csnet-relay)  [ARPA]