From: Ssiddiqi AT InspirePharm DOT Com (Suhaib M. Siddiqi) Subject: Re: G77 fork problems 19 Jan 1999 20:14:50 -0800 Message-ID: <004101be43b3$ae3c58b0$29acdfd0.cygnus.gnu-win32@InspirePharm.Com> Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit To: "Mumit Khan" , "Dave Love" Cc: , , 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 AT inspirepharm DOT com http://www.inspirepharm.com ============================ ----- Original Message ----- From: Dave Love To: Mumit Khan Cc: ; ; Sent: Tuesday, January 19, 1999 8:45 AM Subject: Re: G77 fork problems >>>>>> "MK" == Mumit Khan 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. > - For help on using this list (especially unsubscribing), send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".