home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.21 / text0128.txt < prev    next >
Encoding:
Text File  |  1990-10-26  |  1.7 KB  |  40 lines
  1. Submitted-by: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
  2.  
  3. In article <539@usenix.ORG> peter@ficc.ferranti.com (Peter da Silva) writes:
  4. > But where things have moved closer
  5. > to the underlying principles (everything is a file, for example) it's become
  6. > the better for it.
  7.  
  8. The underlying principle is that everything is a file *descriptor*.
  9.  
  10. > > Sometimes there are objects which would be
  11. > > reasonable to treat with filesystem semantics for which there is no
  12. > > reasonable mechanism for introducing them into the filesystem name
  13. > > space.
  14. > This seems reasonable, but the rest is a pure argument from authority.
  15. > Could you repeat these arguments for the benefit of hose of us who don't
  16. > have the good fortune to know these networking experts you speak of?
  17.  
  18. The filesystem fails to deal with many (most?) types of I/O that aren't
  19. reliable, static, and local. Here's an example: In reality, you initiate
  20. a network stream connection in two stages. First you send off a request,
  21. which wends its way through the network. *Some time later*, the response
  22. arrives. Even if you aren't doing a three-way handshake, you must wait a
  23. long time (in practice, up to several seconds on the Internet) before
  24. you know whether the open succeeds.
  25.  
  26. In the filesystem abstraction, you open a filename in one stage. You
  27. can't do anything between initiating the open and finding out whether or
  28. not it succeeds. This just doesn't match reality, and it places a huge
  29. restriction on programs that want to do something else while they
  30. communicate.
  31.  
  32. You can easily construct other examples, but one should be enough to
  33. convince you that open() just isn't sufficiently general for everything
  34. that you might read() or write().
  35.  
  36. ---Dan
  37.  
  38. Volume-Number: Volume 21, Number 129
  39.  
  40.