Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!haven!rutgers!att!cbnews!trm
From: trm@cbnews.ATT.COM (Tom R. Mueller)
Newsgroups: comp.lang.c++
Subject: Objects and Shared Memory
Summary: What is the best way to mix objects and shared memory?
Message-ID: <5462@cbnews.ATT.COM>
Date: 6 Apr 89 19:29:44 GMT
Reply-To: trm@cbnews.ATT.COM (Tom R. Mueller)
Organization: AT&T Bell Laboratories
Lines: 36

Does anyone know of solutions for the problems associated with
C++ objects and shared memory in multiple Unix(r) processes.  The
following problems come to mind:

What is a shared object?  An obvious answer is an instantiation using
'new' of a class that overloads new so that the storage is allocated
from shared memory.  Given this answer and assuming that it isn't
possible to cause the shared memory to be mapped to the same virtual
address in every process, there are some more problems.

Shared objects cannot have ordinary pointers inside them.

Shared objects cannot have virtual member functions because they are
implemented with pointers to functions.

These two problems take away many of the benefits afforded by
object-orientation when dealing with shared memory.

What other definitions of a shared object are there?

When two processes both want to access a single shared object, what is
the best way to make this come about?  Should 'new' be required and
then the second process doesn't really get a pointer to a new object
but rather a pointer to an already existing object?  Should
constructors be used and then the constructor doesn't really create a
new object.  Maybe one process should be required to somehow "pass"
the identity of the shared object to the other process.  How should
the semantics be defined?

- Tom Mueller			AT&T Bell Laboratories (CB 0D109)
 (614) 860-5287			6200 East Broad Street
  ...att!cblpn!trm		Columbus, OH  43213
-- 
- Tom Mueller			AT&T Bell Laboratories (CB 0D109)
 (614) 860-5287			6200 East Broad Street
  ...att!cblpn!trm		Columbus, OH  43213