home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / os / vms / 20041 < prev    next >
Encoding:
Text File  |  1992-12-29  |  6.0 KB  |  144 lines
  1. Path: sparky!uunet!olivea!spool.mu.edu!agate!ucbvax!lrw.com!leichter
  2. From: leichter@lrw.com (Jerry Leichter)
  3. Newsgroups: comp.os.vms
  4. Subject: re: Re: flushing in VAXC and DECC [fsync]
  5. Message-ID: <9212291349.AA02953@uu3.psi.com>
  6. Date: 29 Dec 92 12:28:33 GMT
  7. Sender: daemon@ucbvax.BERKELEY.EDU
  8. Organization: The Internet
  9. Lines: 133
  10.  
  11.  
  12.     In article <1992Dec27.055031.24162@eco.twg.com>, larry@eco.twg.com
  13.     (Lawrence B. Henry III) writes:
  14.     [VMS AXP HELP for fsync()]
  15.     >PS. Don't take this serious unless you are one of those people out
  16.     >there posing as a guru.. :-)
  17.  
  18.     Glad to know that it's documented on AXP machines.  Now, perhaps you'd
  19.     clarify a point for us:  The AXP documentation doesn't agree with what
  20.     fsync() acutally does under VMS 5.4-2.  In particular, the AXP
  21.     documentation would have us believe that:
  22.  
  23.         fsync(fileno(stdout));
  24.  
  25.     actually causes the results of, e.g., all printf's to be flushed to
  26.     disk.  Now, under VMS 5.4-2, if you spawn a subprocess (using the
  27.     command "SPAWN/NOWAIT/OUTPUT=file_name RUN program" that runs the
  28.     program
  29.  
  30.         #include stdio
  31.         main()
  32.         {    printf("This is a test.");
  33.             fsync(fileno(stdout));
  34.                 sleep(30);
  35.         }
  36.  
  37.     guess what?  You don't see "This is a test." in the output until the
  38.     process dies.  However, if the program had been:
  39.  
  40.         #include stdio
  41.         main()
  42.         {    printf("This is a test.");
  43.             fflush(stdout);
  44.             fsync(fileno(stdout));
  45.             sleep(30);
  46.         }
  47.     you'd see "This is a test." in the output file right away.
  48.  
  49.     So, as someone "posing as a guru," I'd like to know whether the
  50.     function does as it's documented to do, or whether it does what it
  51.     does under VMS v5.4-2.
  52.  
  53.     (If you don't understand the distinction, that's OK;  You're not
  54.     "posing as a guru")
  55.  
  56. Gee, now *I* get to flame Carl!
  57.  
  58. Carl, you uneducated twit!  Didn't you read my earlier posting on this
  59. subject?  (It hasn't arrived at your site yet, you say?  Hey, fool, if you
  60. aren't going to wait for those who know to explain it to you, why are you
  61. running your mouth off?  And haven't you read the Unix BSD documentation yet?)
  62.  
  63. :-)
  64.  
  65. Seriously, to repeat:
  66.  
  67.     - fsync() is a Unix BSD (4.1BSD in fact, I believe - so quite old)
  68.         invention.
  69.  
  70.     - On Unix, there is a clear division between the operating system I/O
  71.         layer (open(), read(), write()) and the Standard I/O Library
  72.         (fopen(), scanf(), printf()).  You can tell which level a
  73.         routine lives at by looking at how it specifies a file.  The
  74.         Unix layer specifies files using file descriptors, AKA file
  75.         numbers.  The Standard I/O Library specifies them using file
  76.         pointers (objects of type FILE *).  The only user-accessible
  77.         function that crosses layers is fileno(), which gives you the
  78.         file descriptor for the Unix layer file underlying a given
  79.         Standard I/O Library.
  80.  
  81.         Functions that operate at the Unix layer are actually system
  82.         calls (i.e., like VMS system services).  Functions in the
  83.         Standard I/O Library are just normal user-mode code.
  84.  
  85.     - Since, on Unix, fsync() operates at the Unix I/O level, one should
  86.         no more expect it to flush the buffers of the Standard I/O
  87.         layer "above" it than one should expect that, for example,
  88.         intermixing printf's with write's to the underlying file will
  89.         cause things to come out in the right order.  Note that the
  90.         Unix documentation doesn't actually SAY anything about this
  91.         one way or the other; but it should be clear from context.
  92.  
  93.     - On VMS, there's a similar clear distinction (at least to those who
  94.         understand such things) between the VAX C RTL's Unix emulation
  95.         and the underlying RMS services.  The problem people run into
  96.         is that they forget that the line between emulated Unix layer
  97.         calls and emulated Standard I/O Library calls is still there,
  98.         too.  (Or they think it's in another place.  INFO-VAX has seen
  99.         many questions from people who assumed that, for example,
  100.         read() on VMS was "atomic" with respect to signals, as it is
  101.         on Unix, where it's a system call.)
  102.  
  103.         Although they are all part of the VAX C RTL, the Unix layer
  104.         functions are still quite distinct from the Standard I/O
  105.         Library functions.  fsync() does "just what it does on Unix":
  106.         It causes the "system sublayer" (here, RMS) to flush any data.
  107.         It doesn't affect the Standard I/O layer at all.
  108.  
  109.     - A long time ago, I spoke to the VAX C developers about the fsync()
  110.         function.  Apparently the reason it remained undocumented for
  111.         so long - it's a trivial function, maybe 10 instructions
  112.         long - was that there was a debate within the VAX C group as
  113.         to whether fsync() should do an implicit fflush().  The "no"
  114.         side of the argument was "Unix doesn't do it, why should the
  115.         emulation?"  The "yes" side of the argument was "that's right,
  116.         Unix doesn't do it, and it confuses the hell out of people.
  117.         Doing it does NOT violate the specification of the function
  118.         (such as it is) since nothing anywhere tells you when data
  119.         will NOT be flushed for a Standard I/O Library file in Unix;
  120.         why shouldn't we do better?"
  121.  
  122.         Note that doing an implicit fflush() isn't quite trivial since
  123.          there is no way to find the FILE *, if any, that refers to a
  124.         given file descriptor without searching all the files the
  125.         Standard I/O Library has open.  There is no inherent reason
  126.         why there should not be more than one FILE * refering to the
  127.         same file descriptor; in fact, in the DECUS C I/O system, all
  128.         Standard I/O level files that refer to the control terminal
  129.         do share the same file descriptor.  Since the overall design
  130.         of the VAX C RTL's I/O system at least started out modeled on
  131.         DECUS C's, it's possible that it does the same (though I don't
  132.         think so).
  133.  
  134.     - As a final note, in general, where essentially the same function can
  135.         be applied to both the Unix and Standard I/O layers, the
  136.         former will be named "op" while the latter will be named
  137.         "fop", as, for example, in open/fopen, stat/fstat.  This would
  138.         lead you to think that fsync() lived in the Standard I/O layer
  139.         and expected a FILE * argument.  Wrong.  (There is also a
  140.         sync() Unix system call, but it does something different.)
  141.         Consistency?  Don't expect it from Unix.
  142.  
  143.                             -- Jerry
  144.