Re: pfMalloc & object container

New Message Reply Date view Thread view Subject view Author view

Marcus Barnes (marcus++at++multigen.com)
Tue, 28 Apr 1998 14:36:57 -0700


On Apr 28, 9:05am, Jay Gischer wrote:
>David Chan writes:
>
>I don't think that pointers work too well with shared memory here.

Pointers work fine ... as long as they point to other pieces of shared memory.

>If the Console's were allocated from shared memory, their addresses
>will possibly change from process to process. If they weren't the
>memory won't even be there in a different process.

It's generally bad to map a shared memory arena to different base addresses in
cooperating processes. Make sure to create all your shared memory arenas prior
to pfConfig() or fork().

For C++, it is also bad to map a C++ DSO to different addresses because then
those object's vptrs will not be valid between processes [SIGILL typically].
This means that if you use dlopen() to dynamically load a C++ DSO, you must do
it before pfConfig() as well.

>If in fact the Console structures are to be shared, it would be better
>to do:
>
> typedef structure {
> ...
> Console console[10];
> ...
> } SharedData;
>
> and then
>
> SharedData *sd =
(SharedData*)pfMalloc(sizeof(SharedData),pfGetSharedArena);
> sd->console[0] = *new Console(whatever);

This is _not_ a good way to create objects! This invokes the copy constructor
on a temporary object. The object created by the new expression is a memory
leak!

>// This way the console data is sure to be in shared memory too.

No, no, no! The temporary object is _not_ going to be in shared memory.

Regards.

--
+ Marcus Barnes, Technical Staff        mailto:marcus++at++multigen.com +
+ Multigen Inc.                         http://www.multigen.com    +
+ 550 S. Winchester Blvd.               phoneto:1-408-556-2654     +
+ Suite 500 San Jose CA 95128           faxto:1-408-261-4102       +
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer++at++sgi.com
        Admin. requests:  info-performer-request++at++sgi.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:57:19 PDT

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