Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!decwrl!pyramid!ut-sally!seismo!hao!woods
From: woods@hao.UUCP (Greg Woods)
Newsgroups: net.lang.f77
Subject: Re: Attempts at accessing signal(2) from within f77
Message-ID: <1926@hao.UUCP>
Date: Mon, 27-Jan-86 12:45:28 EST
Article-I.D.: hao.1926
Posted: Mon Jan 27 12:45:28 1986
Date-Received: Thu, 30-Jan-86 01:58:53 EST
References: <611@eagle.ukc.UUCP>
Organization: High Altitude Obs./NCAR, Boulder CO
Lines: 61

> I am using Fortran under a 4.1BSD Unix.

   We use 4.2 here. That may or may not make a difference.

> In intro(3) it says "these functions together with those from section 2
> are automatically loaded by cc and f77".

  The term "automatically loaded" means that the library(s) containing them
are searched by default and do not need to be specified when your program 
is linked. They will not actually be loaded unless you reference them. In
addition, f77 also loads the functions from section 3F of the manual.

> 	external junk,signal
> 	call signal(SIGFPE,junk)

> (1)  Am I correct in assumming I can access signal in this way?
>      If not,....why?
> 
> (2)  If one can access signal(2) what am I doing wrong? I'm lost as to
>      whether I'm entering _signal (found in libc.a) or _signal_ (found
>      in libF77.a) when setting everything up and on subsequent calls.

  f77 ALWAYS appends an underscore to routine names. Therefore, the above
call must reference signal_ from libF77.a. I don't know about 4.1, but in
4.2 the arguments to signal(3F) are different from those to signal(3C). 
Specifically, a third argument is required. If this is also the case for 4.1
(perhaps someone still using 4.1 could enlighten us?) then that might explain
why you get a segmentation fault. Missing arguments can do that! :-)
I would suggest that you get out your manual and look under signal(3F). This 
is the only version of "signal" that you will be able to access from FORTRAN.
It has a return value which you should check to make sure your call was
correct. It is an integer function.

> (3)  What are the inner workings involved here, or what should happen
>      if things work?

  If it does work, and the designated signal is received, your handler will
be invoked. Upon return from the handler, your program will continue execution
from the point where the signal occurred. The default action of a signal is
restored when a handler is invoked, so if you still want to catch the signal
on subsequent occurences, you will need to have another call to signal inside
your handler. The handler, unfortunately, may NOT have any arguments. If you
need values passed to it you will have to do it through a common block.
  One problem with catching interrupts using signal calls becomes apparent 
here. Since the default action is restored when the handler is invoked (in
this case, with interrupt, program termination) if the user hits repeated
interrupt signals from the keyboard, the timing may work out such that the
program is terminated anyway (if the second interrupt is received before your
handler can call signal again). In 4.2 this has been fixed with the ability
to "mask" signals (i.e. delay receiving a signal) but that isn't much help
to you right now. Well, this is a very quick and very dirty introduction
to signals from the user point of view. If you REALLY want to know how they 
work, it will be necessary to take a course in the internals of the operating 
system.

--Greg
--
{ucbvax!hplabs | decvax!noao | mcvax!seismo | ihnp4!seismo}
       		        !hao!woods

CSNET: woods@ncar.csnet  ARPA: woods%ncar@CSNET-RELAY.ARPA