home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.20 / text0029.txt < prev    next >
Encoding:
Internet Message Format  |  1990-08-02  |  1.8 KB
  1. From:  Chuck.Phillips@FtCollins.NCR.COM (Chuck.Phillips)
  2.  
  3.  
  4. >>>>> On 23 May 90 16:31:58 GMT, mikes@oakhill.sps.mot.com (Mike Schultz) said:
  5. Mike> For REAL TIME purposes, shared memory functionality  is very useful, but
  6. Mike> REQUIRING it to map files would be unacceptable for many implementations.
  7.  
  8. It *seems* to me that directly implementing mmap() with SVr4 semantics
  9. under VMS, AGEIS (and of course Multics :-) would be possible.  UNIX
  10. appears to be the late comer with shared memory.  Am I missing something?
  11.  
  12. Mike> ...
  13.  
  14. Mike> Now here are the latest developments.  SVR4 has taken the step of
  15. Mike> implementing mmap without requiring it to be a file.  It states that one
  16. Mike> is mapping in a virtual memory object instead.  It may be possible for
  17. Mike> the SVR4 wording of mmap to be used as existing practice.  There will
  18. Mike> have to be some functionality labeled as implementation defined.
  19.  
  20. Regarding IPC and mmap():
  21.  
  22. If I understand the SVr4 implementation of mmap() correctly, it is only
  23. possible to share write enabled memory between processes if mmap()ing a
  24. file system file, but not possible using "anonymous" (a.k.a. swap) memory.
  25. Is it possible, and if it is possible, are you restricted to sharing
  26. anonymous memory between parent and child processes due to lack of a
  27. file system handle?
  28.  
  29. In any case, is (or are there plans for) one of the POSIX groups to address
  30. mmap() (or whatever it will be called) specificly as a method of IPC?  It
  31. appears SVr4 shared memory (shmat(), et al) offers little mmap() does not
  32. (or couldn't easily be added, like handles).
  33.  
  34. Sorry if this posting is redundant.  We only recently started recieving a
  35. full comp.* feed.
  36.  
  37.     Thanks in advance,
  38. --
  39. Chuck Phillips  MS440
  40. NCR Microelectronics             Chuck.Phillips%FtCollins.NCR.com
  41. Ft. Collins, CO.  80525           uunet!ncrlnk!ncr-mpd!bach!chuckp
  42.  
  43. Volume-Number: Volume 20, Number 29
  44.  
  45.