Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!pt.cs.cmu.edu!andrew.cmu.edu!+
From: Richard.Draves@CS.CMU.EDU
Newsgroups: comp.os.mach
Subject: Re: Sharing memory between tasks
Message-ID: 
Date: 3 Oct 89 02:45:21 GMT
References: <8651@spool.cs.wisc.edu>
Sender: rpd@M.GP.CS.CMU.EDU
Organization: Carnegie Mellon, Pittsburgh, PA
Lines: 30
In-Reply-To: <8651@spool.cs.wisc.edu>

> Excerpts from netnews.comp.os.mach: 2-Oct-89 Sharing memory between
> tasks Mike Zwilling@barney.cs. (1240)

> From reading documentation, the steps to do this are:
>     1. Start a parent task that vm_allocate's the common data structure
>     3. Parent uses vm_inherit to set the inheritance properties
>     3. Parent task forks a child task 
>     4. Child task performs an exec to start a program


After step 3, the parent and child tasks are sharing the region of
memory.  The problem is that an exec system call throws away the
caller's address space and builds a new address space.  The child loses
the shared region of memory.

Two possibilities come to mind.  First, Mach 2.5 supports external
memory management.  Among other things, this allows unrelated tasks to
share memory objects.  Mach 2.5 comes with the netmemoryserver program,
which in fact allows tasks on different machines to share a memory
object, with correct read/write semantics.  However, you don't have to
take advantage of that; the tasks sharing a region of memory can be on
the same machine.

Second, you could write/obtain a user-level program loader, and use it
instead of exec to start the new program.  You could tell/hack it to
leave the inherited region of shared memory untouched.  I know there are
program loaders kicking around CMU.  I don't know if there are any that
don't rely on Mach 2.5 features.

Rich