From: winalski@adserv.enet.dec.com (Paul S. Winalski)
Subject: Re: flushing in VAXC and DECC
Reply-To: winalski@adserv.enet.dec.com (Paul S. Winalski)
Organization: Digital Equipment Corporation, Nashua NH
Date: Mon, 28 Dec 1992 23:26:10 GMT


In article <1hn91uINNnna@gap.caltech.edu>,
carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick) writes:
|>
|>In article <1992Dec27.200611.24473@nntpd2.cxo.dec.com>,
|>winalski@adserv.enet.dec.com (Paul S. Winalski) writes:
|>>The function behaves as documented.  It flushes all of the C RTL's internal
|>>buffers and it also does an RMS SYS$FLUSH to force the data to be written to
|>>disk.
|>>
|>>You're being caught by the special RMS processing for process-permanent files.
|>
|>Afraid not.  The same thing happens with the program:
|>	#include stdio
|>	main()
|>	{	FILE *fp;
|>		fp = fopen("TEST.DAT", "w");
|>		fprintf(fp, "This is a test.\n");
|>		fsync(fileno(fp));
|>		sleep(30);
|>	}
|>
|>fsync() *MUST* be preceded by an fflush() if you want to be sure that all stuff
|>that's already been written using standard I/O calls is flushed to disk.  And,
|>byt the way, despite the claim by another person, the program:
|>
|>#include stdio
|>main()
|>{	int fd;
|>	fd = creat("TEST.DAT");
|>	write(fd, "This is a test.\n", 16);
|>	fsync(fd);
|>	sleep(30);
|>}
|>
|>Also exhibits exactly the same behavior.  Unfortunately, there doesn't appear
|>to be any documented way to flush the C I/O buffers if you've been using
|>write() instead of standard I/O.
|>
|>>When you do a SPAWN/NOWAIT/OUT=filespec, SYS$OUTPUT (aka stdout) is opened in
|>>supervisor mode by DCL as a process-permanent file.  This is done so that each
|>>program run in the subprocess doesn't create its own version of the output file.
|>>Many user-mode RMS operations on a process-permanent file end up being no-ops.
|>>Among these are SYS$OPEN, SYS$CLOSE, and SYS$FLUSH.  So what happens here is
|>>that the DECC RTL does write its buffers and do a SYS$FLUSH, but RMS ignores
|>>the SYS$FLUSH because stdout is a process-permanent file.
|>
|>>Note that your second program above (the one with the fflush()) behaves
|>>identically to the first one--you still don't see "This is a test." until the
|>>subprocess terminates.  This is because the fsync()'s SYS$FLUSH is still
|>>being ignored.
|>
|>Have you actually tried this, or are you just making a wild-assed-guess without
|>actually testing your claim?  The reason I ask is that your claim is dead wrong
|>under VMS v5.4-2.  Perhaps it's different under a different version of VMS?

I was very careful to verify my assertions by experiment using DECC under
AXP OpenVMS V1.0 before I wrote them up in my postings (I did the experiments
on Alpha VMS, BTW, because somebody had asked Ehud about DECC's handling of
this situation, and I happened to have an AXP system handy).  It works as I
described using DECC on Alpha AXP VMS systems:  if the file is a PPF, RMS
ignores the $FLUSH that is done by fsync().  However, in all cases, fsync()
causes the C I/O buffers to be flushed.

I can believe that this is not the case under VAX/VMS V5.4-2.  The C I/O
routines were completely rewritten for the DECC RTL, and many bugs and glitches
such as this one were fixed.

--PSW