Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!hao!husc6!encore!paradis
From: paradis@encore.UUCP (Jim Paradis)
Newsgroups: comp.unix.wizards
Subject: Re: Shared Memory in BSD4.3 is lacking?
Message-ID: <2738@encore.UUCP>
Date: 1 Mar 88 19:45:43 GMT
References: <12033@brl-adm.ARPA>
Sender: news@husc6.harvard.edu
Reply-To: paradis@encore.UUCP (Jim Paradis)
Organization: The Whizzo Chocolate Company
Lines: 64

In article <12033@brl-adm.ARPA> rbj@icst-cmr.arpa (Root Boy Jim) writes:
>   From: Chris Torek <chris@trantor.umd.EDU>
>   Nobody was quite sure how mmap `ought' to work, and it never got
>   implemented....
>
>.... in BSD. So those vendors who needed it, SUN and Sequent, implemented
>it *differently*. Encore probably has another variation.
                   ^^^^^^

First, my credentials: I'm a kernel hacker for Encore's Umax4.2 kernel.

Now: If you're running UmaxV on a Multimax, you get System V shared
memory semantics (since UmaxV is SVR3 compatible)

If you're currently running Umax4.2, you get a very simple shared
memory semantic which basically says, "Share this piece of my address
space with any processes that I fork off".  This shared memory does
not survive across an exec, so basically any programs that try to make
use of shared memory have to be monolithic.  Seems crude and ugly, I
know, but you'd be surprised how many programs can be parallelized very
nicely using just this semantic.

For our next major release of Umax4.X, we plan to support System V shared
memory semantics.  "Why?", I hear the BSD fans cry.  Simply because for
good or for ill System V is the ONLY UNIX shared-memory semantic out there 
that more than three people seem to agree upon.  If `mmap' ever gets fully
defined and implemented in the future and there seems to be an audience for
it, then we might add support for it.  Currently, though, we don't have the
resources to go defining standards that nobody's going to want to use 8-).

Trivia bowl time (related to another comp.unix.wizards topic).  Some have
argued that a great way to access shared-memory regions is through the
filesystem namespace.  Well, there is at least one operating system out
there that does just that.  Which OS is that?

[sound of Jeopardy theme music...]



VMS.  They're called "global segments".  Of course, VMS has the interesting
"feature" of not just treating the filesystem object as a handle for the
shared memory region, but also using it to reference a FILE that the region
is paged from/to.  Whether this is good or bad is a mixed bag.  Once the last
person detaches from the global segment, voila` -- you have a regular file
containing the data that was in the global segment (when the file is actually
in use for paging it's inaccessible as a regular file).  This can be seen as
either a benefit or a security risk.  One of the benefits is that once the
last process detaches from the region it remains with its data intact to be
attached by another process, consuming only filesystem space in the interim.
Hell, you could even survive system shutdowns that way! (clean shutdowns only;
no telling what state the file will be in after a crash!)

>   System V shared memory is wrong.
>

Perhaps.  But right now it's the only game in town, unless you're rolling
your own (how's THAT for well-mixed metaphors 8-) )


   +----------------+  Jim Paradis                  linus--+
+--+-------------+  |  Encore Computer Corp.       necntc--|
|  | E N C O R E |  |  257 Cedar Hill St.           ihnp4--+-encore!paradis
|  +-------------+--+  Marlboro MA 01752           decvax--|
+----------------+     (617) 460-0500             talcott--+
Well, what's the pleasure in THAT??!!