Re: Shared Memory Question

New Message Reply Date view Thread view Subject view Author view

Steve Woolsey (woolsr++at++inel.gov)
Tue, 20 Jul 1999 08:19:11 -0600


OK, I agree the shared structure should work. However, I have an undefined
number of objects that is declared at runtime. That is the reason I had the
pfVec3* for location. So I am trying to create an array of pfVec3's that
contains the xyz's for the objects from 0-(numObjects-1). How do I create that
so that it is aout of shared memory and not out of the heap? That is what I
can't figure out. Do I create it with another call to pfCalloc, as done with
the shared structure?

Thanks for you help.

Steve

Angus Dorbie wrote:

> The shared structure approach can work but you should set the DCS
> position in the app after you send the position in the vec. You also
> defeat the purpose of having the pointer in shared memory by newing off
> the heap. That's never going to work. Eliminate the indirection in the
> struct declaration adding the vec data to the shared structure.
>
> The second suggestion you make is also worrying. The stack will have
> completely different data. The pointer could work provided you asign it
> before the pfConfig AND allocate it from shared memory. I suspect you
> don't.
>
> Joaquín Casillas wrote:
> >
> > Steve Woolsey escribió:
> > >
> > > I have an app I am doing in C++ that is forking a motif process and
> > > another process to calculate the movements for a number of object. I am
> > > trying to get the location of the object to pass back to the draw
> > > process, so I can update the pfDCS's. I have tried three different
> > > approaches, with no success.
> > >
> > > 1. I tried putting a pfVec3 into the Shared struct.
> > >
> > > typedef struct {
> > > pfPipeWindow *pw;
> > > pfChannel *chan;
> > > pfScene *scene;
> > > int exitFlag;
> > > pfDCS **objectDCS;
> > > pfVec3 *objectLocation;
>
> No, just use pfVec3 objectLocation; and access members with . instead of
> ->
>
> > > int numObjects;
> > > }SharedData;
> > >
> > > Then I tried declaring the pointer with:
> > >
> > > Shared->objectLocation = new pfVec3[numObjects];
> > >
>
> This won't work, the new is going to create unshared data, so the
> pointer will be shared but will point to invalid memory in other
> processes.
>
> > > 2. Tried declaring a pfDataPool in the main process, and then attaching
> > > the movement process.
> > >
> > > pfDataPool *pool;
> > > pfVec3 *objectLocation;
> >
> > Steve, another approach may be to fork a compute process that calculates
> > the movements of the objects and then use the mechanism of
> > pfFlux/pfEngine/pfFCS (use pfFCS's instead of pfDCS's for the moving
> > objects).
>
> The problems seem considerably more basic than this. There are
> fundamental problems with his notion of how shared memory should be
> created w.r.t. the fork.
>
> Cheers,Angus.
>
> --
> Never express yourself more clearly than you think.
> Neils Bohr
>
> For advanced 3D graphics Performer + OpenGL based examples and tutors:
> http://www.dorbie.com/
> -----------------------------------------------------------------------
> List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com

--
-------------------------------------------------------------------
Steven Woolsey                         Associate Engineer/Scientist
Lockheed Martin Idaho Technologies     Visualization Engineer
Idaho National Engineering Lab.        EMAIL: woolsr++at++inel.gov
P.O. Box 1625, M.S. 3605
Idaho Falls, ID  83415-3605
-------------------------------------------------------------------

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Tue Jul 20 1999 - 07:19:18 PDT

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