Re: Real-time Database Manipulations
John Rohlf (jrohlf++at++tubes)
Tue, 11 Jul 95 14:58:04 PDT
>
> All right, so I've spent several months working on code which I knew broke a
> basic rule of Performer. On the Indigo2 that I've been developing on,
> everything seemed fine, so I assumed that I had gotten away with something
> despite the protests of my resident Performer notable ( Mr. Marrou :) ).
>
> I am working on producing free play destructable buildings. On the Indigo2,
> (or an Onyx 4 CPU in APPCULLDRAW), I modify the Performer tree from a sproc'ed
> and haven't had any problems. As someone obviuosly knew, my cute little trick
> doesn't woek well at all on the Onyx in multiprocess mode. The problem that I
> have now is how to correct my obviuos mistake without destroying the neat class
> structure that I developed in the process. (I'd also like to keep from
> hampering the overall applications speed anymore than I have to.)
>
> >From what I understand, in Performer 1.2, I will have to move all of my
> Performer Tree manipulation into the APP process if I want the system to work
> properly. In Performer 2.0, it looks like I could use the pfBuffers in order
> to do almost exactly what I'm doing now.
>
> I guess my question boils down to this: is there any way that I can generate
> ANY perform tree infromation in a process sproc'ed off the APP and get the
> system to work?
Unfortunately no.
> (And maybe someone could give a brief reason for why heirarchy construction is
> limited to the APP process. Preferrably something more than the "just because"
> that I'm getting from the guys here.)
Performer has global, internal data structures which you
will collide on when sproc'ed since sproc'ed processes
normally share address space. With fork() and pfBuffer in
2.0 you will be able to asynchronously create hierarchies.
This archive was generated by hypermail 2.0b2
on Mon Aug 10 1998 - 17:51:40 PDT