Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!cs.utexas.edu!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.unix.questions
Subject: Re: Shared Mem, Msg queues, Semaphores  Code fragments wanted
Keywords: IPC XENIX shared memory segments interprocess communication
Message-ID: <2331@auspex.auspex.com>
Date: 3 Aug 89 18:30:30 GMT
References: <100@norsat.UUCP> <30715@ism780c.isc.com> <2313@auspex.auspex.com> <1989Aug2.155906.18506@robohack.uucp>
Reply-To: guy@auspex.auspex.com (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 21

>SysV IPC is a poor solution for a very common problem.  A better
>solution is a good implementation of named pipes for message queues,

I think S5R4 will have a way of attaching a stream to a file name, so
that users opening the file, in effect, establish a connection to the
process on the other end of the stream; I think that, unlike named
pipes, this works similarly to the "connect" socket call, so each
connection gets a unique descriptor in the server, so it can more easily
keep the conversations separate.  The descriptor also refers to a
stream, so that e.g. message boundaries can be preserved.

>use a form of the /proc filesystem for shared memory,

Uhh, why "/proc"?  That seems like a poor solution, too, especially
considering that the standard form won't work - you have to be the owner
of a process, or the super-user, to open its "/proc" file (for obvious
reasons!).  Instead, what you want is to have some way of using a plain
file as the item at which the processes rendezvous; this can be done in
S5R4 by having both processes "mmap" the file MAP_SHARED, which maps the
file into their address space such that if you modify a page in the
mapped region it ends up modifying the file.