home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.20 / text0016.txt < prev    next >
Encoding:
Internet Message Format  |  1990-08-02  |  2.1 KB
  1. From:  mikes@oakhill.sps.mot.com (Mike Schultz)
  2.  
  3. In article <700@longway.TIC.COM> From:  karish@mindcrf.uucp
  4. >In article <696@longway.TIC.COM> [Doug Gwyn] writes:
  5. >>Like calling mmap() instead of whatever the POSIX routine is.
  6. >
  7. >I hope we don't have to name a new interface every time a new standard
  8. >restricts or changes the syntax of an old one.  Especially when the
  9. >old interface is difficult to use portably anyway.
  10.  
  11. I can't tell if you are for or against the use of the new interface,
  12. especially with the comment about the "difficult to use portably anyway"
  13. comment.
  14.  
  15. The reason that the new interface was choosen is this:
  16.  
  17. For REAL TIME purposes, shared memory functionality  is very useful, but
  18. REQUIRING it to map files would be unacceptable for many implementations.  Even
  19. the suggestion that the file would be on a RAM disk is not acceptable.  The
  20. application should be able to request the shared memory to be mapped in
  21. and that is the LAST thing that the operating system should HAVE to do with
  22. it.
  23.  
  24. Thus P1003.4 needed an interface that did not require that files be mapped.
  25. Mmap was existing practice, but it would have to be gutted in order to
  26. used it.  It was felt that there was two courses to take here, both of which
  27. was certain to draw ballot objections.
  28.  
  29. The solution choosen was one that was a subset of mmap's functionality, but
  30. was not the same interface.  This had two advantages:  First, it could be
  31. implemented with mmap using macros.  Second, if an implementation wished
  32. to contain a pure shared memory interface, without routing it thru the
  33. blasted file system, it could do that as well as implementing mmap.
  34.  
  35. Anyway, that was the reasoning then.
  36.  
  37. Now here are the latest developments.  SVR4 has taken the step of implementing
  38. mmap without requiring it to be a file.  It states that one is mapping in
  39. a virtual memory object instead.  It may be possible for the SVR4 wording of
  40. mmap to be used as existing practice.  There will have to be some functionality
  41. labeled as implementation defined.
  42.  
  43. We'll see how it goes.
  44.  
  45. Mike Schultz
  46. mikes@oakhill.mot.sps.com
  47.  
  48. And soon to be 
  49.  
  50. ms@RMC.Liant.com
  51.  
  52. Volume-Number: Volume 20, Number 16
  53.  
  54.