Re: Seperate ISECT process
John Rohlf (jrohlf++at++tubes)
Tue, 21 Jun 94 11:42:37 PDT
>
>
>
> To: info-performer++at++sgi.com
>
>
> Hi,
>
> A week ago I came up with a problem regarding the use of a separate isect
> process, but unfortunately I did not receive an answer. Therefore I am sending
> the message again in case it was never received.
>
> *****************************************************************************
>
> My application uses a separate process for intersection calls.
> (pfMultiprocess(PFMP_FORK_ISECT)).
>
>
> It seems that Performer lacks a two-way path between the APP process
> and the ISECT process. Currently changes done in the ISECT structure,
> in the APP process, are passed down to the isect_func() (the ISECT cb),
> but sadly enough it is not true the other way around.
>
> Since isects are done in a separate process and they are quite lengthy in time,
> it may take the process some time to come up with a result (could even take a
> couple of frames). Therefore it is important that a two-way data path is
> available between the two processes to enable a hand-shaking mechanism.
>
>
> Well, could or should Performer support a two-way data path?
> Meanwhile, is the only solution is the use of a globally defined, pre pfConfig,
> structure?
Performer is conceptually structured as pipelines, either
intersection or drawing, where data flows only downstream. The
semantics of upstream data propagation are a bit sticky so we've
left it up to the user. A pre-pfConfig-allocated chunk of shared memory
or pfDataPool should work fine for APP/ISECT handshaking.
This archive was generated by hypermail 2.0b2
on Mon Aug 10 1998 - 17:50:21 PDT