home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / sys / sgi / 11101 < prev    next >
Encoding:
Text File  |  1992-07-21  |  4.2 KB  |  153 lines
  1. Newsgroups: comp.sys.sgi
  2. Path: sparky!uunet!mcsun!dxcern!burow
  3. From: burow@dxcern.cern.ch (Burkhard Burow)
  4. Subject: trouble with f77 and named pipes
  5. Message-ID: <1992Jul21.100630.11396@dxcern.cern.ch>
  6. Organization: CERN European Laboratory for Particle Physics
  7. Date: Tue, 21 Jul 1992 10:06:30 GMT
  8. Lines: 143
  9.  
  10.  
  11. I'm having trouble using named pipes with SGI's f77. My troubles get worse
  12. with the newer software releases.
  13.  
  14. SUMMARY: I'd like SGI f77 to behave like DECFortran w.r.t. named pipes.
  15.          i.e. - The READONLY specifier in the OPEN allows Fortran to read from
  16.                 a named pipe and recognize the EOF when the partner program has
  17.                 closed the pipe.
  18.               - Without the READONLY specifier Fortran can write to a named
  19.         pipe, blocking etc. as usual.
  20.  
  21. My observations of SGI and Ultrix Fortran with named pipes follows. 
  22. If I'm doing something goofy please tell me!
  23.  
  24. I'm currently running a simulation program on ~40 DECstations in parallel and
  25. the main input and output streams for each instance of the program go through
  26. named pipes and on to the manager-program. In a month I'll have access to
  27. 32 4D/35's. 
  28. [Not using named pipes is NOT an option. I'm using an application written for
  29.  one proccessor, and use named pipes to allow the unmodified application to
  30.  continue to think that it is running on a single processor.]
  31.  
  32. thanks,
  33. burkhard   burow@vxdesy.cern.ch
  34.  
  35. -------begin observations from Fortran/named pipe tests------------------
  36.  
  37. Ultrix  == DECFortran 3.1 running under Ultrix 4.2 on a DECstation.
  38. 4D/25   == f77 (versions says ftn 90/10/02) under IRIX 3.3.1 on a 4D/25
  39. Crimson == f77 (versions says ftn 06/01/92) under IRIX 4.0.4
  40.  
  41. Fortran reading from a named pipe:
  42. ----------------------------------
  43.  
  44. unix> cat > i.f
  45.       program i
  46.       open (unit=11,status='unknown',form='formatted',file='pipe'
  47.      +      ,readonly)
  48.       do 100 i=1,10000
  49.          read (unit=11,fmt=*,end=999) n
  50.          print *, n
  51.  100  continue
  52.  999  continue
  53.       close (unit=11)
  54.       end
  55. ^D
  56. unix> f77 -o i i.f
  57. unix> cat > data
  58. 1
  59. 2
  60. 3
  61. 4
  62. ^D
  63. unix> mknod pipe p
  64.  
  65. Then, 
  66.  
  67. unix> cat data > pipe & i
  68.  and
  69. unix> i >& temp & cat data > pipe && cat temp
  70.  
  71. work as expected on the 4D/25 (not the Crimson) and Ultrix.
  72. i.e. It doesn't matter which process connects first, and the Fortran program
  73.      can read from the named pipe.
  74.  
  75. Ultrix - 
  76. If I remove the READONLY specifier from the OPEN, DECFortran will never see EOF
  77. from the named pipe when the writing process closes its connection. The 4D/25
  78. doesn't care about the READONLY and continues to work normally without it.
  79.  
  80. Crimson -
  81. I can't get Fortran to recognize 'EOF' for a named pipe. The only way I can get
  82. the program to stop reading from the pipe is to send 'bad' input data so that
  83. the program exits. e.g.
  84. Crimson> i >& i.log&
  85. [2] 24448
  86. Crimson> cat data > pipe&
  87. [3] 24449
  88. Crimson>
  89. [3]    Done                   cat data > pipe
  90. Crimson> echo junk > pipe
  91. Crimson>
  92. [2]    Exit 112               i >& i.log
  93. Crimson> cat i.log
  94. list input: incomprehensible list input
  95. apparent state: unit 11 named pipe
  96. last format: list io
  97. lately reading sequential formatted external IO
  98.             1
  99.             2
  100.             3
  101.             4
  102. Crimson>
  103.  
  104. Again, this behavior is independent of using the READONLY specifier in OPEN.
  105.  
  106.  
  107. Fortran writing to a named pipe:
  108. --------------------------------
  109.  
  110. unix> cat > o.f
  111.       program o
  112.       open (unit=11,status='unknown',form='formatted',
  113.      +      file='pipe')
  114.       write (unit=11,fmt=*) 'hi, how are you ?'
  115.       end
  116. ^D
  117. unix> f77 -o o o.f
  118. unix> mknod pipe p
  119.  
  120.  
  121. Now,
  122.  
  123. Ultrix> o & cat pipe > temp
  124.  and
  125. Ultrix> o & cat pipe > temp
  126.  
  127. works, but on the 4D/25
  128.  
  129. 4D/25> o&
  130. 4D/25> cat pipe > temp&
  131. 4D/25> echo > pipe
  132.  
  133. 'works'. i.e. A third process has to write to the pipe, and hangup, before the
  134. original processes will. Note that if you switch the order of the processes
  135. connecting to the pipe, 
  136.  
  137. 4D/25> cat pipe > temp&
  138. 4D/25> o&
  139.  
  140. nothing will be transferred through the pipe.
  141.  
  142. The Crimson doesn't write to a named pipe. It makes the connection, but doesn't
  143. ouput anything. e.g.
  144. Crimson> mknod pipe p
  145. Crimson> cat pipe >& o.log&
  146. [2] 24408
  147. Crimson> o
  148. [2]  - Done                   cat pipe > & o.log
  149. Crimson> cat o.log
  150. Crimson>
  151.  
  152. -------end observations from Fortran/named pipe tests------------------
  153.