home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.21 / text0195.txt < prev    next >
Encoding:
Text File  |  1990-10-26  |  2.8 KB  |  57 lines
  1. Submitted-by: ok@goanna.cs.rmit.OZ.AU (Richard A. O'Keefe)
  2.  
  3. In article <13220@cs.utexas.edu>, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
  4. > Now we're looking at another possible addition to UNIX that hasn't been
  5. > widely tested: a unified namespace for opening all I/O objects. But we
  6. > already have a unified file descriptor abstraction for reading, writing,
  7. > and manipulating those objects, as well as passing them between separate
  8. > processes. Why do we need more?
  9.  
  10. If you have to use different functions for creating file descriptors
  11. in the first place, then you haven't got a unified file descriptor
  12. abstraction.  Suppose I want to write a "filter" program that will
  13. merge two streams.  It would be nice if I could pass descriptors to
  14. a program, but that's not how most UNIX shells work; I have to pass
  15. strings.  Now, my filter knows what it *needs* (sequential reading
  16. with nothing missing or out of order, but if the connection is lost
  17. somehow it's happy to drop dead) so it could easily do
  18.     fd = posix_open(argv[n], "read;sequential;reliable;soft");
  19. and then it can use any file, device, or other abstraction which will
  20. provide this interface.  My program *can't* know what's available.
  21. If someone comes along with a special "open hyperspace shunt" function;
  22. my program can't benefit from it.  If hyperspace shunts are in the
  23. global name space and posix_open() understands their name syntax, my
  24. program will work just fine.
  25.  
  26. Surely this is the point?  We want our programs to remain useful when
  27. new things are added that our programs could meaningfully work with.
  28.  
  29. I can see the point in saying "shared memory segments aren't much like
  30. transput; let's keep them out of the global name space", but sockets
  31. and NFS files and such *are* "transput-like".  Anything which will
  32. support at least sequential I/O should look like a file.  If that
  33. means that some things in the global name space are "real UNIX files"
  34. with full 1003.1 semantics but some things aren't, that's ok as long
  35. as my programs can find out whether they've got what they need.
  36.  
  37. One point to bear in mind is that application programs written in
  38. C, Fortran, Ada, &c are likely to map file name strings in those
  39. languages fairly directly to strings in the POSIX name space; to
  40. keep something that _could_ have supported C, or Fortran, or Ada
  41. transput requests out of the file name space is to make such things
  42. unavailable to portable programs.  If some network connections can
  43. behave like sequential files (even if they don't support full 1003.1
  44. semantics), then why keep them out of reach to portable programs?
  45.  
  46. (I have used a system where a global name space was faked by the RTL.
  47. Trouble is, different languages did it differently, if at all...)
  48.  
  49. Even shared memory segments *could* support read, write, lseek...
  50.  
  51. -- 
  52. Fear most of all to be in error.    -- Kierkegaard, quoting Socrates.
  53.  
  54.  
  55. Volume-Number: Volume 21, Number 190
  56.  
  57.