Path: utzoo!attcan!uunet!cs.utexas.edu!longway!std-unix
From: mikes@sybil.uucp (Mike Schultz)
Newsgroups: comp.std.unix
Subject: Re: Common Reference Ballot
Message-ID: <763@longway.TIC.COM>
Date: 1 Jul 90 17:48:10 GMT
Sender: std-unix@longway.TIC.COM
Reply-To: std-unix@uunet.uu.net
Lines: 36
Approved: jsq@longway.tic.com (Moderator, John S. Quarterman)
Original-Date: Sun Jun 17 09:45:41 1990

From:  mikes@sybil.uucp (Mike Schultz)

[ I thought I posted this one a couple weeks ago, but apparently I
missed it while I was at USENIX.  Sorry about that.  -mod ]

> From:  Chuck.Phillips@FtCollins.NCR.COM (Chuck.Phillips)
> 
> 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?

Yes, imbedded controllers that may not have a real file system.

> 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?

I'm afraid that I don't understand your question here.  It is .4's specific
goal to not restrict which processes have access to the shared memory.

> 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).

I don't know.

Mike Schultz
sybil!mikes@oakhill.sps.mot.com

Volume-Number: Volume 20, Number 78