home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / vmsnet / vmsposi / 78 < prev   
Encoding:
Internet Message Format  |  1992-11-10  |  1.5 KB

  1. Path: sparky!uunet!noc.near.net!inmet!bu.edu!decwrl!elroy.jpl.nasa.gov!nntp-server.caltech.edu!eql.caltech.edu!rankin
  2. From: rankin@eql.caltech.edu (Pat Rankin)
  3. Newsgroups: vmsnet.vms-posix
  4. Subject: Re: strange posix timing bevavior
  5. Message-ID: <10NOV199219584662@eql.caltech.edu>
  6. Date: 11 Nov 92 02:58:00 GMT
  7. References: <1992Oct31.003920.17824@wega.rz.uni-ulm.de> <2TN8ZVH@gwdu03.gwdg.de>
  8. Organization: California Institute of Technology
  9. Lines: 24
  10. NNTP-Posting-Host: eql.caltech.edu
  11. News-Software: VAX/VMS VNEWS 1.41
  12.  
  13. In article <2TN8ZVH@gwdu03.gwdg.de>, moeller@gwdgv1.gwdg.de writes...
  14. [...]
  15. > I guess this problem is not particular to POSIX:
  16. > The VAXC I/O library has always been famous for doing very inefficient
  17. > I/O to disk, spending 1 I/O per disk block read or written.
  18.  
  19.      VMS POSIX does not use VAXCRTL at all; it has an entirely separate
  20. C run-time library.  However since the POSIX command itself executes
  21. from the regular VMS environment (from DCL that is), _it_ might be using
  22. VAXCRTL.  POSIX$RUN.EXE is not linked to shareable VAXCRTL, but could be
  23. linked with the object library instead.  The point is moot if it doesn't
  24. use C I/O to write to SYS$OUTPUT.
  25.  
  26.      How about testing a third case for additional comparison?
  27.  $!test3.com
  28.  $! ignore SYS$OUTPUT
  29.  $ posix posix$bin:uuencode. "test.gif test.gif >test.uue
  30.  $ logout/full
  31. This one would presumeably end up going through the UCX NFS I/O subsystem,
  32. so may be slow too.  On the other hand, NFS probably uses substantial
  33. buffering to cut down on actual I/O.
  34.  
  35.         Pat Rankin, rankin@eql.caltech.edu
  36.