G77 fork problems

Suhaib M. Siddiqi Ssiddiqi@InspirePharm.Com
Tue Jan 19 07:06:00 GMT 1999


Dave,
thanks for your help.

Mumits suggestion actually worked for me.  What I have is a very simple
FORK call in FORTRAN. Since SGI F77 supports it directly, without
writing a wraper, I assumed the G77 would too. It was my wrong
assumption.  Actually G77 way of handeling FORK makes more sense to
me -- personally.

Regards
Suhaib

--

      INTEGER FORK,IRTN,ISTATE
C**
C**   WE START BY FORKING TO MAKE A PARENT AND A CHILD PROCESS.
C**

      IRTN=FORK()
C**
C**   NOW IRTN WILL BE NEGATIVE IF AN ERROR HAS OCCURRED.   IT WILL BE
C**   ZERO FOR THE CHILD PROCESS, AND WILL HAVE THE (POSITIVE) PROCESS
C**   IDENTIFICATION NUMBER (PID) FOR THE PARENT PROCESS.
C**
      IF (IRTN.LT.0) GO TO 100
      IF (IRTN.EQ.0) GO TO 1000
C**
C**   HERE WE KILL OFF THE PARENT.   ON SILICON GRAPHICS SYSTEMS
C**   RUNNING FORTRAN WE CALL EXIT LIKE A SUBROUTINE.   WHEN THE
C**   PARENT HAS DIED, THE SYSTEM PROMPT SHOULD RETURN.
C**
      CALL EXIT(ISTATE)
      STOP
C**
  100 WRITE (IPDB,116)
  116 FORMAT (/,/,
     +'  (P116-E)  PROBLEM FORKING ON THIS UNIX SYSTEM.',/,
     +'            CHECK SUBROUTINE: GFORK IN FILE GRIDU.F',/)
      STOP
C**
 1000 CONTINUE
C**
C**   HERE WE LET THE CHILD GO ON RUNNING IN THE BACKGROUND.
C**
      RETURN
C**
      END
----
*************************************************
Suhaib M. Siddiqi, Ph.D.
Senior Research Chemist
Inspire Pharmaceuticals, Inc.
4222 Emperor Blvd., Suite 470
Durham, NC 27703-8466

Tel: 919-941-9777 Ext. 238
Fax: 919-941-9797
E-Mail: Ssiddiqi@inspirepharm.com
http://www.inspirepharm.com

============================




----- Original Message -----
From: Dave Love <d.love@dl.ac.uk>
To: Mumit Khan <khan@xraylith.wisc.edu>
Cc: <ssiddiqi@ipass.net>; <gnu-win32@cygnus.com>; <egcs-bugs@cygnus.com>
Sent: Tuesday, January 19, 1999 8:45 AM
Subject: Re: G77 fork problems


>>>>>> "MK" == Mumit Khan <khan@xraylith.wisc.edu> writes:
>
> MK> Here's a start. Note that it's completely untested -- the
> MK> includes I've used (eg., unistd.h) may not even exist on your
> MK> system, pid_t may not be the same as g77 "integer" type, etc etc.
>
>If you want to do that I think you have at least to worry about the
>i/o state and it's not clear what good it is in the absence of a
>corresponding exec, for which there isn't an obvious implementation.
>




More information about the Gcc-bugs mailing list