Common Reference Ballot

[Chuck.Phillips]

From:  Chuck.Phillips at FtCollins.NCR.COM (Chuck.Phillips)


>>>>> On 23 May 90 16:31:58 GMT, mikes at oakhill.sps.mot.com (Mike Schultz) said:
Mike> For REAL TIME purposes, shared memory functionality  is very useful, but
Mike> REQUIRING it to map files would be unacceptable for many implementations.

It *seems* to me that directly implementing mmap() with SVr4 semantics
under VMS, AGEIS (and of course Multics :-) would be possible.  UNIX
appears to be the late comer with shared memory.  Am I missing something?

Mike> ...

Mike> Now here are the latest developments.  SVR4 has taken the step of
Mike> implementing mmap without requiring it to be a file.  It states that one
Mike> is mapping in a virtual memory object instead.  It may be possible for
Mike> the SVR4 wording of mmap to be used as existing practice.  There will
Mike> have to be some functionality labeled as implementation defined.

Regarding IPC and mmap():

If I understand the SVr4 implementation of mmap() correctly, it is only
possible to share write enabled memory between processes if mmap()ing a
file system file, but not possible using "anonymous" (a.k.a. swap) memory.
Is it possible, and if it is possible, are you restricted to sharing
anonymous memory between parent and child processes due to lack of a
file system handle?

In any case, is (or are there plans for) one of the POSIX groups to address
mmap() (or whatever it will be called) specificly as a method of IPC?  It
appears SVr4 shared memory (shmat(), et al) offers little mmap() does not
(or couldn't easily be added, like handles).

Sorry if this posting is redundant.  We only recently started recieving a
full comp.* feed.

	Thanks in advance,
--
Chuck Phillips  MS440
NCR Microelectronics 			Chuck.Phillips%FtCollins.NCR.com
Ft. Collins, CO.  80525   		uunet!ncrlnk!ncr-mpd!bach!chuckp

Volume-Number: Volume 20, Number 29