home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / arch / 11925 < prev    next >
Encoding:
Text File  |  1992-12-24  |  1.5 KB  |  34 lines
  1. Newsgroups: comp.arch
  2. Path: sparky!uunet!inmos!titan.inmos.co.uk!news
  3. From: conor@lion.inmos.co.uk (Conor O'Neill)
  4. Subject: UNIX fseek time (was Re: Comparison of Alpha, MIPS and PA-RISC-II wanted)
  5. Message-ID: <1992Dec24.112422.12434@titan.inmos.co.uk>
  6. Sender: news@titan.inmos.co.uk
  7. Organization: INMOS Limited, Bristol, UK
  8. References: <1992Dec20.164501.291@rlgsc.com> <1992Dec21.194657.759@qb.rhein-main.de> <fW0DHHa@quack.sac.ca.us>
  9. Date: Thu, 24 Dec 1992 11:24:22 GMT
  10. Lines: 22
  11.  
  12. In article <fW0DHHa@quack.sac.ca.us> dfox@quack.sac.ca.us (David Fox) writes:
  13. >
  14. >>Honestly it's the definition of IO that's missing here. C/UNIX
  15. >>have standardized on NOT sequential but flat direct-access files
  16. >>for the filesystem and sequential access for pipes, some devices,
  17. >>input format for most system commands, etc.
  18. >
  19. >That's an interesting point.  I am not an expert in Unix file access
  20. >but I'd guess that Unix has standardized on both sequential
  21. >and flat direct-access files, and that sequential access is just a
  22. >special case of direct access: read so many bytes sequentially from
  23. >a randomly-accessible point in a file.  Or, it has standardized on
  24. >sequential file access, and that direct access is a special case, using
  25. >the fseek() library call.
  26.  
  27. But, given that 'fseek' is incredibly slow on most Unix systems,
  28. one could almost assume that Unix doesn't support random-access files.
  29.  
  30. ---
  31. Conor O'Neill, Software Group, INMOS Ltd., UK.
  32. UK: conor@inmos.co.uk        US: conor@inmos.com
  33. "It's state-of-the-art" "But it doesn't work!" "That is the state-of-the-art".
  34.