home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / v21 / 129 < prev    next >
Internet Message Format  |  1990-12-05  |  2KB
  1. From std-unix-request@uunet.uu.net  Tue Sep 25 10:20:43 1990
  2. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  3.     id AA24327; Tue, 25 Sep 90 10:20:43 -0400
  4. Posted-Date: 24 Sep 90 21:40:07 GMT
  5. Received: by cs.utexas.edu (5.64/1.76) 
  6. From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
  7. Newsgroups: comp.std.unix
  8. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  9. Message-Id: <541@usenix.ORG>
  10. References: <495@usenix.ORG> <523@usenix.ORG> <539@usenix.ORG>
  11. Sender: jsq@usenix.ORG
  12. Organization: IR
  13. X-Submissions: std-unix@uunet.uu.net
  14. Date: 24 Sep 90 21:40:07 GMT
  15. Reply-To: std-unix@uunet.uu.net
  16. To: std-unix@uunet.uu.net
  17.  
  18. Submitted-by: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
  19.  
  20. In article <539@usenix.ORG> peter@ficc.ferranti.com (Peter da Silva) writes:
  21. > But where things have moved closer
  22. > to the underlying principles (everything is a file, for example) it's become
  23. > the better for it.
  24.  
  25. The underlying principle is that everything is a file *descriptor*.
  26.  
  27. > > Sometimes there are objects which would be
  28. > > reasonable to treat with filesystem semantics for which there is no
  29. > > reasonable mechanism for introducing them into the filesystem name
  30. > > space.
  31. > This seems reasonable, but the rest is a pure argument from authority.
  32. > Could you repeat these arguments for the benefit of hose of us who don't
  33. > have the good fortune to know these networking experts you speak of?
  34.  
  35. The filesystem fails to deal with many (most?) types of I/O that aren't
  36. reliable, static, and local. Here's an example: In reality, you initiate
  37. a network stream connection in two stages. First you send off a request,
  38. which wends its way through the network. *Some time later*, the response
  39. arrives. Even if you aren't doing a three-way handshake, you must wait a
  40. long time (in practice, up to several seconds on the Internet) before
  41. you know whether the open succeeds.
  42.  
  43. In the filesystem abstraction, you open a filename in one stage. You
  44. can't do anything between initiating the open and finding out whether or
  45. not it succeeds. This just doesn't match reality, and it places a huge
  46. restriction on programs that want to do something else while they
  47. communicate.
  48.  
  49. You can easily construct other examples, but one should be enough to
  50. convince you that open() just isn't sufficiently general for everything
  51. that you might read() or write().
  52.  
  53. ---Dan
  54.  
  55. Volume-Number: Volume 21, Number 129
  56.  
  57.