home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.20 / text0079.txt < prev    next >
Encoding:
Internet Message Format  |  1990-08-02  |  1.4 KB
  1. From:  mikes@sybil.uucp (Mike Schultz)
  2.  
  3. [ I thought I posted this one a couple weeks ago, but apparently I
  4. missed it while I was at USENIX.  Sorry about that.  -mod ]
  5.  
  6. > From:  Chuck.Phillips@FtCollins.NCR.COM (Chuck.Phillips)
  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. Yes, imbedded controllers that may not have a real file system.
  13.  
  14. > Regarding IPC and mmap():
  15. > 
  16. > If I understand the SVr4 implementation of mmap() correctly, it is only
  17. > possible to share write enabled memory between processes if mmap()ing a
  18. > file system file, but not possible using "anonymous" (a.k.a. swap) memory.
  19. > Is it possible, and if it is possible, are you restricted to sharing
  20. > anonymous memory between parent and child processes due to lack of a
  21. > file system handle?
  22.  
  23. I'm afraid that I don't understand your question here.  It is .4's specific
  24. goal to not restrict which processes have access to the shared memory.
  25.  
  26. > In any case, is (or are there plans for) one of the POSIX groups to address
  27. > mmap() (or whatever it will be called) specificly as a method of IPC?  It
  28. > appears SVr4 shared memory (shmat(), et al) offers little mmap() does not
  29. > (or couldn't easily be added, like handles).
  30.  
  31. I don't know.
  32.  
  33. Mike Schultz
  34. sybil!mikes@oakhill.sps.mot.com
  35.  
  36. Volume-Number: Volume 20, Number 78
  37.  
  38.