Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!wuarchive!emory!hubcap!ncrcae!oiscola!kornegay
From: kornegay@oiscola.Columbia.NCR.COM (h)
Newsgroups: comp.lang.c++
Subject: Object instances in shared memory?
Message-ID: <332@oiscola.Columbia.NCR.COM>
Date: 9 Jan 91 14:27:00 GMT
Reply-To: kornegay@oiscola.UUCP (Michael L. Kornegay)
Distribution: na
Organization: n/a
Lines: 36

I would like to solve the following problem.  

An object having instance variables containing pointers to other objects 
(all in shared memory) and having virtual functions (contains a vptr) is 
constructed in shared memory by overriding operator new.  The methods and 
virtual function tables are in a shared code segment (eg: DLL, shared 
library, shared image).  This object in constructed in shared memory by
one process, and I want to be able to invoke its methods and refer to its
instance variables in both the creating process and other processes.

Note the problems areas:
  Many implementations map shared memory at DIFFERENT virtual addresses
  in each process associated with the shared memory (OS/2 excepted, and
  Unix shmat()'s shmaddr provides some capability).

  Many implementations of shared code segments (eg: DLL, shared libraries,
  shared images) map shared code at DIFFERENT virtual addresses in each
  process associated with the shared code (OS/2 excepted).

  Any pointers in this object instance (in instance variables and in the 
  vptr) are only valid in the process that constructed the object (assuming 
  above comments).  Other processes cannot successfully reference these
  pointers.

The actual target is Unix SVR4 using shared memory and shared libraries.
I can use shmaddr of shmat() in each process to force that the shared
memory areas are at the same virtual addresses in each process, but have
no control on where shared libraries are loaded causing the methods and
virtual function tables to reside at DIFFERENT virtual addresses in each
process.

Anyone having a solution to a similar problem or other ideas?  Thanks.
-- 
----------
Michael L. Kornegay,
  kornegay@oiscola.columbia.ncr.com