NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/os/vms/19930

Text File | 1992-12-27 | 3.6 KB | 89 lines

Newsgroups: comp.os.vms
Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!cs.utexas.edu!wupost!emory!swrinde!elroy.jpl.nasa.gov!decwrl!deccrl!news.crl.dec.com!dbased.nuo.dec.com!nntpd.lkg.dec.com!nntpd2.cxo.dec.com!adserv.enet.dec.com!winalski
From: [e-mail] (Paul S. Winalski)
Subject: Re: flushing in VAXC and DECC
Message-ID: <[e-mail]>
Lines: 76
Sender: [e-mail] (USENET News System)
Reply-To: [e-mail] (Paul S. Winalski)
Organization: Digital Equipment Corporation, Nashua NH
References: <[e-mail]> <[e-mail]>,<[e-mail]> <[e-mail]>
Date: Sun, 27 Dec 1992 20:06:11 GMT


In article <[e-mail]>,
[e-mail] (Carl J Lydick) writes:

[regarding fsync()]
|>
|>Glad to know that it's documented on AXP machines.  Now, perhaps you'd clarify
|>a point for us:  The AXP documentation doesn't agree with what fsync() acutally
|>does under VMS 5.4-2.  In particular, the AXP documentation would have us
|>believe that:
|>    fsync(fileno(stdout));
|>actually causes the results of, e.g., all printf's to be flushed to disk.
|>Now, under VMS 5.4-2, if you spawn a subprocess (using the command
|>"SPAWN/NOWAIT/OUTPUT=file_name RUN program" that runs the program
|>    #include stdio
|>    main()
|>    {    printf("This is a test.");
|>        fsync(fileno(stdout));
|>        sleep(30);
|>    }
|>guess what?  You don't see "This is a test." in the output until the process
|>dies.  However, if the program had been:
|>    #include stdio
|>    main()
|>    {    printf("This is a test.");
|>        fflush(stdout);
|>        fsync(fileno(stdout));
|>        sleep(30);
|>    }
|>you'd see "This is a test." in the output file right away.
|>
|>So, as someone "posing as a guru," I'd like to know whether the function does
|>as it's documented to do, or whether it does what it does under VMS v5.4-2.

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.
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.

If you change the first program to read:

    #include stdio
    #include signal
        main()
        {
        FILE *x;
        x = fopen ("x.x", "w");
        fprintf(x, "This is a test.");
        fsync(fileno(x));
        sleep(30);
        }

and then run it using the command SPAWN/NOWAIT/OUT=Y.Y RUN program
you will find that the fsync() flushes "This is a test." to file X.X as the
fsync() documentation would lead one to believe.  It works in this case because
fopen() has opened X.X as a normal RMS file; it is not a process-permanent file,
and so fsync()'s SYS$FLUSH call is honored.

fsync(), incidentally, normally is only available on AXP if you compile your
program /STANDARD=VAXC.

--PSW