home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / os / vms / 20036 < prev    next >
Encoding:
Text File  |  1992-12-29  |  2.9 KB  |  67 lines
  1. Path: sparky!uunet!usc!news.service.uci.edu!ucivax!news.claremont.edu!nntp-server.caltech.edu!SOL1.GPS.CALTECH.EDU!CARL
  2. From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
  3. Newsgroups: comp.os.vms
  4. Subject: Re: flushing in VAXC and DECC
  5. Date: 29 Dec 1992 23:43:17 GMT
  6. Organization: HST Wide Field/Planetary Camera
  7. Lines: 53
  8. Distribution: world
  9. Message-ID: <1hqnqlINNg7b@gap.caltech.edu>
  10. References: <1hjtr9INN34t@gap.caltech.edu> <1992Dec27.200611.24473@nntpd2.cxo.dec.com> <1hn91uINNnna@gap.caltech.edu>,<3088@anprda.atson.asahi-np.co.jp>
  11. Reply-To: carl@SOL1.GPS.CALTECH.EDU
  12. NNTP-Posting-Host: sol1.gps.caltech.edu
  13.  
  14. >     Anyway, this does not invalidate my argument.  Since fsync is named
  15. >after the unix function (though actual semantics is quite different;  as
  16. >you know, on unix "written" data are immediatedly shared among processes.
  17. >Fsync() merely guarantees the data is on disk and can be considered safe
  18. >from crash), it should reasonably imitate unix behaviour - no wonder you
  19. >need fflush() before fsync().
  20.  
  21. Well, as I pointed out to Jerry Leichter in e-mail, I think a better emulation
  22. of UNIX behavior would involve having (groan) yet another set of I/O buffers in
  23. the VAXC RTL, so we'd have:
  24.     1)  The buffers associated with emulation of the UNIX standard I/O
  25.         library (e.g. printf(), etc.);
  26.     2)  The buffers associated with emulation of UNIX I/O system calls
  27.         (e.g., write(), etc.);
  28.     3)  The actual RMS buffers.
  29. Doing it that way, fflush() would simply force the data from the first type of
  30. buffer into the corresponding buffer of the second type, while fsync() would
  31. force the contents of the second type of buffer into the RMS buffers and
  32. execute a SYS$FLUSH.  Doing it that way would make porting code somewhat easier,
  33. since then the emulation of the UNIX I/O system would be considerably more
  34. accurate.
  35.  
  36. Of course, that would make the VAXC RTL I/O routines even slower than they
  37. already are.
  38.  
  39. It would also have been nice if there were an equivalent of fflush() that works
  40. with a file descriptor rather than a file pointer.  Of course, the workaround
  41. is to do an fdopen() to get a file pointer to pass to fflush():
  42.  
  43. #include stdio
  44. main()
  45. {    int i, fd;
  46.     FILE *fp;
  47.  
  48.     {    fd = creat("TEST.DAT");
  49.         write(fd, "This is a test.\n", 16);
  50.         fp = fdopen(fd, "a");
  51.         fflush(fp);
  52.         fsync(fd);
  53.         sleep(30);
  54.     }
  55. }
  56.  
  57. It'd also be nice if DEC would clarify the documentation for fsync() that was
  58. previously mentioned in this thread.
  59. --------------------------------------------------------------------------------
  60. Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL
  61.  
  62. Disclaimer:  Hey, I understand VAXen and VMS.  That's what I get paid for.  My
  63. understanding of astronomy is purely at the amateur level (or below).  So
  64. unless what I'm saying is directly related to VAX/VMS, don't hold me or my
  65. organization responsible for it.  If it IS related to VAX/VMS, you can try to
  66. hold me responsible for it, but my organization had nothing to do with it.
  67.