Re: multipipe problems, Need help, VLIB, MP, Boom, Fakespace

New Message Reply Date view Thread view Subject view Author view

John Rohlf (jrohlf++at++tubes)
Tue, 22 Nov 94 11:00:36 PST

> We'd like to structure the code so that we have at least 1
> process per pipe.
>
> GL seems to have the rendering window as a state variable (ie,
> I set the current window via a winset() and then all rendering
> happens on that window).

        This is correct.

> We're doing an sproc(). Do we have to do a heavyweight fork()
> instead? Ie, if we do a fork(), we now have another copy of the
> GL library, such that each process now has its state variable for
> the current rendering window. My concern with doing a fork() is
> that it will be more difficult to manage things without the
> shared memory.

        You have to use fork() in IrisGL so each process has its
own current window. IMO fork is a cleaner mechanism than
sproc because it requires explicit memory sharing. With sproc you
can be sloppy and get away with it most of the time. sproc is
useful for simple programs but quickly becomes too inflexible
by its draconian sharing of everything.

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

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