Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!nbires!isis!udenva!rneitzel
From: rneitzel@udenva.UUCP (RICHARD NEITZEL )
Newsgroups: comp.unix.questions
Subject: Re: question about signal
Message-ID: <4248@udenva.UUCP>
Date: Thu, 1-Oct-87 10:03:10 EDT
Article-I.D.: udenva.4248
Posted: Thu Oct  1 10:03:10 1987
Date-Received: Mon, 5-Oct-87 08:21:05 EDT
References: <720001@hpclmar.HP.COM>
Reply-To: rneitzel@udenva.UUCP (RICHARD NEITZEL )
Organization: U of Denver
Lines: 51

In article <720001@hpclmar.HP.COM> mar@hpclmar.HP.COM (Michelle Ruscetta) writes:
>
> Question about signal():
>
>  Should the return from a signal handling routine specified by a call
>  to signal() go to the instruction which caused the signal, or to the 
>  instruction immediately following that which caused the signal?
>
>  For example: 
>
>  void (*p_my_handler)();
>
>  main()
>  {  
>     extern void my_handler();
>     int y = 0;
>     int x = 3;
>     p_my_handler = my_handler:
>     signal(SIGFPE, p_my_handler);    
>     x = x/y; 			      /* should my_handler return to here? */
>     printf("return from signal\n");  /* or should my_handler return to here? */
>  }

In my opinion this depends partially on the way in which you look at the
problem. Returning to the line that caused the signal
might well trigger the signal again, putting the program into an infinite loop.
After all, the chances of your signal handling routine knowing EXACTLY what to
do are slim. 

There is however the problem that a C line does not map to a single
machine instruction. For example, suppose that the line above where changed to:
	x = x/y + (x - y);
Now, do you want the entire line to complete, even if the division triggers a 
signal? More then likely, yes you do.

The answer probably is that there need to be two classes of signals (whether
in fact or in conception), synchronous and asynchronous. The first should be 
used for events that are of a fixed nature, such as floating point exceptions.
The latter are for events that are unpredictable. Further, synchronous 
signals should be limited to events from which you do not normally exspect to
return, while the other case is for events that do not require that the normal
program flow be terminated. 

It is my opinion that the best solution would be to have these two types of
signals, but barring that I would prefer that all signals behave in an 
asynchronous nature, leaving it to the user to use those signals that are
inappropriate in a strictly synchronous manner.

'I'd gladly pay you Tuesday for a hamburger today'

			Richard Neitzel