home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.21 / text0183.txt < prev    next >
Encoding:
Text File  |  1990-10-26  |  2.4 KB  |  57 lines
  1. Submitted-by: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
  2.  
  3. In article <106697@uunet.UU.NET> peter@ficc.ferranti.com (Peter da Silva) writes:
  4.   [ Programs depend on write() working. ]
  5.  
  6. On the contrary. When the descriptor is unreliable, you get an I/O
  7. error or the data is simply corrupted; this is exactly what happens with
  8. disk I/O. Programs that handle errors on read() and write() are more
  9. robust than programs that don't.
  10.  
  11. More commonly, when the descriptor is dynamic and the other side drops,
  12. you get a broken pipe. This is certainly not a rare failure mode.
  13.  
  14. In context, I said that open() is only appropriate for reliable, static,
  15. local I/O objects. You seem to be arguing that read() and write(), and
  16. file descriptors in general, also require reliable, static, local I/O
  17. objects, and so my distinction is silly. But UDP sockets, pipes, and TCP
  18. sockets are unreliable, dynamic, and remote file descriptors
  19. respectively, and read()/write() work with them perfectly.
  20.  
  21. > > You can read() or
  22. > > write() reasonable I/O objects through file descriptors. Very few
  23. > > programs---the shell is a counterexample---need to worry about what it
  24. > > takes to set up those file descriptors.
  25. > And that's the problem, because the shell is the program that is used to
  26. > create more file descriptors than just about anything else. If the shell
  27. > had a syntax for creating sockets and network connections we wouldn't be
  28. > having this discussion...
  29.  
  30. Oh? Really? I have a syntax for creating sockets and network connections
  31. from my shell. For example, I just checked an address by typing
  32.  
  33.   $ ctcp uunet.uu.net smtp sh -c 'echo expn rsalz>&7;echo quit>&7;cat<&6'
  34.  
  35. So we shouldn't be having this discussion, right?
  36.  
  37. > but then if it did then you might as well make
  38. > it be via filenames...
  39.  
  40. Why? I don't see a natural filename syntax for TCP connections, so why
  41. should I try to figure one out? What purpose would it serve? Only two
  42. programs---a generic client and a generic server---have to understand
  43. the filenames. If those two programs work, what's the problem?
  44.  
  45.   [ shm and sem are reliable, static, local ]
  46.  
  47. As a BSD addict I don't have much experience with those features, but I
  48. believe you're right. So feel free to put shared memory objects into the
  49. filesystem; I won't argue. Semaphores, I'm not sure about, because it's
  50. unclear what a file descriptor pointing to a semaphore should mean. Are
  51. semaphores I/O objects in the first place?
  52.  
  53. ---Dan
  54.  
  55. Volume-Number: Volume 21, Number 182
  56.  
  57.