home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / v21 / 182 < prev    next >
Internet Message Format  |  1990-12-05  |  3KB
  1. From jsq@cs.utexas.edu  Thu Oct  4 14:39:03 1990
  2. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  3.     id AA20321; Thu, 4 Oct 90 14:39:03 -0400
  4. Posted-Date: 3 Oct 90 20:49:11 GMT
  5. Received: by cs.utexas.edu (5.64/1.77) 
  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: <13195@cs.utexas.edu>
  10. References: <529@usenix.ORG> <548@usenix.ORG> <106697@uunet.UU.NET>
  11. Sender: jsq@cs.utexas.edu
  12. Organization: IR
  13. X-Submissions: std-unix@uunet.uu.net
  14. Date: 3 Oct 90 20:49:11 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 <106697@uunet.UU.NET> peter@ficc.ferranti.com (Peter da Silva) writes:
  21.   [ Programs depend on write() working. ]
  22.  
  23. On the contrary. When the descriptor is unreliable, you get an I/O
  24. error or the data is simply corrupted; this is exactly what happens with
  25. disk I/O. Programs that handle errors on read() and write() are more
  26. robust than programs that don't.
  27.  
  28. More commonly, when the descriptor is dynamic and the other side drops,
  29. you get a broken pipe. This is certainly not a rare failure mode.
  30.  
  31. In context, I said that open() is only appropriate for reliable, static,
  32. local I/O objects. You seem to be arguing that read() and write(), and
  33. file descriptors in general, also require reliable, static, local I/O
  34. objects, and so my distinction is silly. But UDP sockets, pipes, and TCP
  35. sockets are unreliable, dynamic, and remote file descriptors
  36. respectively, and read()/write() work with them perfectly.
  37.  
  38. > > You can read() or
  39. > > write() reasonable I/O objects through file descriptors. Very few
  40. > > programs---the shell is a counterexample---need to worry about what it
  41. > > takes to set up those file descriptors.
  42. > And that's the problem, because the shell is the program that is used to
  43. > create more file descriptors than just about anything else. If the shell
  44. > had a syntax for creating sockets and network connections we wouldn't be
  45. > having this discussion...
  46.  
  47. Oh? Really? I have a syntax for creating sockets and network connections
  48. from my shell. For example, I just checked an address by typing
  49.  
  50.   $ ctcp uunet.uu.net smtp sh -c 'echo expn rsalz>&7;echo quit>&7;cat<&6'
  51.  
  52. So we shouldn't be having this discussion, right?
  53.  
  54. > but then if it did then you might as well make
  55. > it be via filenames...
  56.  
  57. Why? I don't see a natural filename syntax for TCP connections, so why
  58. should I try to figure one out? What purpose would it serve? Only two
  59. programs---a generic client and a generic server---have to understand
  60. the filenames. If those two programs work, what's the problem?
  61.  
  62.   [ shm and sem are reliable, static, local ]
  63.  
  64. As a BSD addict I don't have much experience with those features, but I
  65. believe you're right. So feel free to put shared memory objects into the
  66. filesystem; I won't argue. Semaphores, I'm not sure about, because it's
  67. unclear what a file descriptor pointing to a semaphore should mean. Are
  68. semaphores I/O objects in the first place?
  69.  
  70. ---Dan
  71.  
  72. Volume-Number: Volume 21, Number 182
  73.  
  74.