Re: shared memory object classes

New Message Reply Date view Thread view Subject view Author view

Smith, Jeff W. (jsmith++at++smtpgate.gstone.com)
Mon, 27 Feb 1995 08:54:38 -0800


> From: Jim Helman
>Subject: Re: shared memory object classes
> Date: Friday, February 24, 1995 6:12PM

> problems occur when you have processes in which the code for your C++
> objects lives at different addresses in different processes, in
> particular if you are sharing memory between unrelated execuatables
> (e.g. pfDataPools) and potentially in related processes if you load
> C++ objects via DSO's after a fork. But even in these cases, I
> believe that with some ld work one can usually get the C++ DSO's
> located at the same addresses in both executables without conflicts.

Has anyone done this? I would like to implement this if someone can
give me more details on "some Id work?, and "getting C++ DSO's located
at the same address?". Is this done through the loader?

I am currently successfully using C++ objects out of shmem with vtbls, but I

would like to use unrelated executables and shmem as the above suggests.

Jim or anyone?

 - Jeff WS
jsmith++at++gstone.com


New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:51:00 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.