Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!ucbvax!UM.CC.UMICH.EDU!Tim_Buxton
From: Tim_Buxton@UM.CC.UMICH.EDU
Newsgroups: comp.sys.sgi
Subject: Nonflushing fclose() is a PROBLEM
Message-ID: <8810253@um.cc.umich.edu>
Date: 15 Jun 91 14:10:58 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The Internet
Lines: 59

Netlanders:
 
We are having serious intermittent problems as we *try* to communicate
between processes  using fscanf() and fprintf().  We had used
pipes previously, with success.  When we added signal handling
to the processes however, the pipes "broke", and according to the
documentation, this is Just the Way It Is; pipes become nonblocking
when signals are used.  Writing to/reading from a scratch file
seemed a logical alternative.
 
Our problem seems to happen because the system INSISTS on
writebehind buffering with fprintf(), and the fscanf() just
plows ahead and tries to read junk when the fprintf() output
is delayed by other traffic on the system.  The only way
we have found to fix the problem is to put a sleep() command
in to (maybe) insure the system has time to flush its buffer.
This is clearly unreliable, however.  Has anyone found a
workaroud to this problem?
 
The code works (roughly) as follows:
 
 PROCESS 1
 
       .
       .
       .
  fp=fopen("file"...
  fprintf(fp,"%s\n", stuff....
  fclose(fp); /* this does not flush the buffer before proceeding*/
  <send signal to process 2 that file is complete>
 
 
 PROCESS 2
 
       .
       .
       .
  <wakes up on signal from PROCESS 1>
  sleep(2);  /* this works but is wasteful and undependable */
  fp=fopen("file"...
  fscanf(fp,"%s", maybegarbage ); /* here the problem
                                  happens when garbage
                                  is read in sometimes */
 
/* end of pseudocode */
 
 
The Hotline has said yes, this is a problem, but that the low-level
open(fileid, O_SYNC|WRITEONLY); would *actually* flush the buffer
*before* sending the signal in PROCESS 1.  This will involve rewriting
substantial code, and I would appreciate hearing about easier workarounds
that others have found.  Whatever we find to be easiest, I will
summarize to the net once we prove it works.  Thanks.
 
                         Tim Buxton
                         OptiMetrics, Inc.
                         Tim_Buxton@um.cc.umich.edu