Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!sri-unix!ctnews!pyramid!uccba!hal!oxtrap!rich
From: rich@oxtrap.UUCP
Newsgroups: comp.lang.c++
Subject: Re: C++ on the sequent
Message-ID: <300@oxtrap.UUCP>
Date: Fri, 14-Aug-87 19:08:27 EDT
Article-I.D.: oxtrap.300
Posted: Fri Aug 14 19:08:27 1987
Date-Received: Sun, 16-Aug-87 09:37:06 EDT
References: <2943@uw-june.UUCP>
Reply-To: rich@oxtrap.UUCP (K. Richard Magill)
Distribution: world
Organization: Oxford TP, Ann Arbor
Lines: 31
Keywords: C++, sequent, multi-processor

In article <2943@uw-june.UUCP> brian@uw-june.UUCP (Brian Bershad) writes:
>I am trying to port c++ v1.2 to the sequent. ...
>
>The problem is that Sequent has decided to "extend" 
>C by adding two new storage specifiers:
>
>	shared
>	private
>
>which indicate to the C compiler whether globals
>should be declared private to each process,
>or shared among all processes.

(DYNIX has 3 segments, code, data, shared-data)

My answer is don't bother.  Sequent has provided us with a number of
techniques for using shared memory, one of which is the "shared"
keyword.  I find the shared data segment distastful for several
reasons.  First, It only gives you shared memory if your processes
derive from a common ancestor through forks only, that is, it is lost
on exec.  Second is a religious viewpoint; if it isn't ansii, it isn't
C.  (Third, it breaks undump, unexec, etc.!)

You really have at least 2 alternatives that I can see.  Use either
mmap with unlinked files, (new processes can't rendevous after the
unlinking), or the SysV shmem stuff.  Mmap is virtually portable,
(entendre intended), while shared and private aren't even C.

rich.
{cbosgd!hal, pyramid!fmsrl7}!oxtrap!rich (oxtrap is a b8000)
"Lies keep people happy" - I94 west of Detroit