Path: utzoo!attcan!uunet!decwrl!sgi!shinobu!odin!bennett
From: bennett@sgi.com (Jim Bennett)
Newsgroups: comp.sys.sgi
Subject: Re: multi-processes and GL windows
Message-ID: <1990Oct11.202617.27495@odin.corp.sgi.com>
Date: 11 Oct 90 20:26:17 GMT
References: <6353@uceng.UC.EDU>
Sender: news@odin.corp.sgi.com (Net News)
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 43

In article <6353@uceng.UC.EDU> trohling@uceng.UC.EDU (tom rohling) writes:
>
>       Is it possible to have a graphics process create child processes that
>    are still allowed to render to the parent process's graphics window?
>
>       A possible scenario would be something like this:  The main graphics
>    program would fork a process to monitor some device so as
>    not to keep the main process all tied up with the little book-keeping 
>    tasks.  But at the same time, it would be nice if the child process could
>    update its information on the main process's window where all the status 
>    information would be kept/displayed.  The problem I forsee in this is
>    the event queue (mainly) and the matrix stack for that specific window.
>
>       Any hints/past experiences would be appreciated.
>
>                                              Thanks,
> 
>                                              Tom Rohling
>                                              University of Cincinnati
>              

Yes, this feature was added in 3.3.  The major restrictions are:

	1.  The child process has to be created with sproc() and it
	    must share at least the address space of the parent.

	2.  It is the application's responsibility to semaphore every
	    graphics call to guarantee that every graphics call is
	    atomic.

The reason for #2 is that it would be possible to interrupt process A
in the middle of a call, when not all of the tokens have been sent down,
and schedule process B, which could then make a graphics call.

The tokens from process B would go into the pipe in the middle of the
tokens from process A, and get misinterpreted, with the probable result
of crashing the microcode.

Of course, the semaphores could (and probably should) be placed at a
higher level than at the every graphics call level.  But the idea is
the same.

Jim Bennett				(bennett@esd.sgi.com)