Re: Real-time Database Manipulations

New Message Reply Date view Thread view Subject view Author view

`Bwana' Bob Buckley (bbuckley++at++ctaeng.com)
Wed, 12 Jul 1995 13:13:54 -0600

On Jul 11, 2:58pm, John Rohlf wrote:
> Subject: Re: Real-time Database Manipulations
> >
> > 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 4CPU 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 nowis how tocorrect my obvious mistake withoutdestroying 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 APPprocess 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.
>

Or allocate your performer hierarchy prior to a fork (not a sproc) and no
dynamic allocation/deallocation is done afterwards. Or make allowances for
dynamic allocations/deallocation prior to a fork by creating enough performer
structures to handle the run. Lance knows the tricks.

>
> > (And maybe someone could give abrief reason forwhy heirarchy construction
is
> > limited tothe 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.
>
>
>
>-- End of excerpt from John Rohlf

===========================================================================
'Bwana' Bob Buckley CTA, Inc.
Sr. Software Engineer 5670 Greenwood Plaza Blvd
Visual Systems Englewood, CO 80111
(303) 889-1207 (303) 889-1200
bbuckley++at++ctaeng.com (303) 889-1398 Fax
===========================================================================

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:41 PDT

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