home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!olivea!charnel!rat!usc!howland.reston.ans.net!sol.ctr.columbia.edu!hamblin.math.byu.edu!hellgate.utah.edu!asylum.cs.utah.edu!clark
- From: clark%asylum.cs.utah.edu@cs.utah.edu (Charles Clark)
- Newsgroups: comp.lang.c++
- Subject: Re: Objects in Shared Memory
- Message-ID: <1993Jan25.105459.4799@hellgate.utah.edu>
- Date: 25 Jan 93 17:54:58 GMT
- References: <19930125.084616.825@almaden.ibm.com>
- Sender: clark@cs.utah.edu
- Followup-To: comp.lang.c++
- Organization: University of Utah Computer Science
- Lines: 26
-
- In article <19930125.084616.825@almaden.ibm.com> jimi@vnet.ibm.com (Jim Meyers) writes:
- >>
- >>The first of these approaches is not complete in that it does not
- >>address the problem of intra-object references. Thus, virtual base classes
- >>can not be used in the inheritance hierarchy of the shared objects.
- >
- >This is not all clear to me... Can you elaborate on why you believe that
- >Jordan's method does not support intra-object references?
-
- After reviewing Jordan's paper, I see that intra-object references will
- resolve correctly (Jim, thanks for pointing this out). His method
- requires that, not only the location of the vtable be coordinated, but
- also the location of the shared memory segment be coordinated. This means
- that each process which accesses the shared memory segment must attach
- that memory segment at the same virtual memory address. With the memory
- segment at the same vm address, the intra-object references will resolve
- correctly.
-
- Straying from the orignal subject a little, how can the location of the
- shared memory segments be coordinated? The vtable location is fixed at
- link edit time, thus one would know then whether there is a conflict.
- Since the creation and attachment of the shared memory segment is at run-
- time, how can one ensure that the vm address of each of the cooperating
- processes will be available?
-
- --Charles
-